Methods and systems for network-enabled account creation using optical detection

ABSTRACT

Provided is a network-enabled method for creating an online account using a network of devices. The method comprises: receiving by an authentication system, a request to create an online account with an online server; generating a visual graphical code by the authentication system, which is displayed on a display screen and comprises a validation identity; acquiring image data of the visual graphical code from a user device with aid of optical detection apparatus, by capturing an image of the visual graphical code displayed on the display screen; processing the image data to extract the validation identity; based on the validation identity identifying an online serve provider associated with the online server and user information categories associated with the online account; and based on identification information related to the user identifying the user, and the data to the online server for the online account with the online server.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a Continuation application of U.S. application Ser.No. 16/432,119, filed on Jun. 5, 2019, which is a Continuationapplication of International PCT Application No. PCT/US2017/065790,filed on Dec. 12, 2017, which claims the priority and benefit of U.S.Provisional Application No. 62/432,855 filed on Dec. 12, 2016, U.S.Provisional Application No. 62/458,985 filed on Feb. 14, 2017, and U.S.Provisional Application No. 62/492,384 filed on May 1, 2017, each ofwhich is incorporated by reference herein in its entirety.

BACKGROUND

Identity theft has become a serious problem for both online users andonline service providers. In certain instances, users may pose as otherusers to defraud online service providers or, alternatively, fraudulentindividuals or entities may pose as authentic online service providersto defraud users. To counter increasingly creative methods of identitytheft, online service providers have started to add more layers ofsecurity measures to verify an individual's identity, such as byrequiring more user credentials. When opening an account, for example,an online service provider can request personal and sensitiveinformation.

Oftentimes, manually completing these information requests can becumbersome, time-consuming, and redundant for users. It can deter usersfrom opening accounts with the online service provider requesting suchinformation. In other instances, a user may be providing information toa fake service provider posing as an authentic service provider, riskinga serious identity security hazard.

SUMMARY

Recognized herein is the need for methods and systems for authenticatingusers and online service providers before opening an online account, andallowing users to open an online account with minimal user input.

In one aspect, a method for creating an online account using a networkof devices is provided. The method may comprise: (a) receiving, by anauthentication system, a request by a user to create an online accountwith an online server; (b) generating a visual graphical code inresponse to said request, by the authentication system, wherein thevisual graphical code is configured to be displayed on a display screenand comprises a validation identity; (c) acquiring image data of thevisual graphical code from a user device with aid of optical detectionapparatus, wherein the image data is acquired by capturing an image ofthe visual graphical code displayed on the display screen using animaging device operably coupled to the user device and configured tooptically detect the visual graphical code; (d) processing said imagedata to extract the validation identity; (e) based on the validationidentity, identifying an online serve provider associated with theonline server and one or more user information categories associatedwith the online account to be created with the online server; and (f)based on identification information related to the user, identifying theuser, and providing information data for the user information categoriesto the online server for the online account to be created with theonline server.

In some embodiments, the display screen is external to the user device.In some cases, the method further comprises identifying the one or moreuser information categories that is not pre-stored with theauthentication system, and prompting the user to provide informationaccording to the identified one or more user information categories viathe user device. In some embodiments, the visual graphical code is aone-time barcode that is uniquely associated with opening the onlineaccount. In some embodiments, the validation identity is associated withthe online server or the online service provider that is operating theonline server. In some embodiments, the identification informationrelated to the user comprises a device identifier of the user device. Insome embodiments, the identification information is pre-stored with theauthentication device. In some embodiments, the method further comprisesreceiving nonce data along with the image data for detecting a replayattack. In some cases, the nonce data comprises at least two of thefollowing: (i) one or more operational parameters of the imaging, (ii)positional information about the imaging device or the user device, and(iii) characteristics of the image data derived from image processing ofthe image data. In some cases, the nonce data comprises a physical stateof the user device that is obtained by one or more sensors.

In another aspect, an authentication system for creating an onlineaccount using a network of devices is provided. The system may comprise:an authentication server in communication with a user device configuredto permit a user to create an online account with an online server,wherein the authentication server comprises: (i) a memory for storing aset of software instructions, user information data for each of aplurality of users and a plurality of information categories uniquelyassociated with each of a plurality of users, and (ii) one or moreprocessors configured to execute the set of software instructions to:(a) receive a request by a user to create an online account with theonline server; (b) generate a visual graphical code in response to saidrequest, wherein the visual graphical code is configured to be displayedon a display screen and comprises a validation identity; (c) acquireimage data of the visual graphical code from a user device with aid ofoptical detection apparatus, wherein the image data is acquired bycapturing an image of the visual graphical code displayed on the displayscreen using an imaging device operably coupled to the user device andconfigured to optically detect the visual graphical code; (d) processthe image data to extract the validation identity; (e) based on thevalidation identity, identify an online service provider associated withthe online server and one or more of the plurality of user informationcategories associated with the online account to be created with theonline server; and (f) based on identification information related tothe user, identify the user, and provide information data for the one ormore user information categories to the online server for the onlineaccount to be created with the online server.

In some embodiments, the display screen is external to the user device.In some embodiments, the visual graphical code is a one-time barcodethat is uniquely associated with opening the online account. In someembodiments, the validation identity is associated with the onlineserver or the online service provider that is operating the onlineserver. In some embodiments, the identification information related tothe user comprises a device identifier of the user device. In someembodiments, the identification information is pre-stored with theauthentication system. In some embodiments, the method further comprisesreceiving nonce data along with the image data for detecting a replayattack. In some cases, the nonce data comprises at least two of thefollowing: (i) one or more operational parameters of the imaging, (ii)positional information about the imaging device or the user device, and(iii) characteristics of the image data derived from image processing ofthe image data. In some cases, the nonce data comprises a physical stateof the user device that is obtained by one or more sensors. In someembodiments, online service provider is pre-registered with the system.

Additional aspects and advantages of the present disclosure will becomereadily apparent to those skilled in this art from the followingdetailed description, wherein only illustrative embodiments of thepresent disclosure are shown and described. As will be realized, thepresent disclosure is capable of other and different embodiments, andits several details are capable of modifications in various obviousrespects, all without departing from the disclosure. Accordingly, thedrawings and description are to be regarded as illustrative in nature,and not as restrictive.

INCORPORATION BY REFERENCE

All publications, patents, and patent applications mentioned in thisspecification are herein incorporated by reference to the same extent asif each individual publication, patent, or patent application wasspecifically and individually indicated to be incorporated by reference.To the extent publications and patents or patent applicationsincorporated by reference contradict the disclosure contained in thespecification, the specification is intended to supersede and/or takeprecedence over any such contradictory material.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features of the invention are set forth with particularity inthe appended claims. A better understanding of the features andadvantages of the present invention will be obtained by reference to thefollowing detailed description that sets forth illustrative embodiments,in which the principles of the invention are utilized, and theaccompanying drawings (also “Figure” and “FIG.” herein), of which:

FIG. 1 shows a schematic diagram of a user device capturing a graphicalbarcode during an authentication session.

FIG. 2 shows a schematic diagram of users and online service providersusing an authentication system to verify the identities of the usersand/or the online service providers.

FIG. 3 shows examples of user information data that may be stored foreach user and/or each user device.

FIG. 4 shows a flow diagram of the authentication system providing userinformation to an online service provider.

FIG. 5 shows an exemplary network layout comprising one or moreauthentication systems.

FIG. 6 shows a schematic block diagram of an exemplary system and methodfor opening an online account using a code.

FIG. 7 shows a flow diagram of an overview of the online account openingprocess.

FIG. 8 shows a schematic illustration of a user device capturing avisual graphical barcode during an authentication session.

FIG. 9 illustrates an example of a user device collecting nonce data.

FIG. 10 schematically illustrates a system implementing the identityproofing and authentication method.

FIG. 11 illustrates an exemplary method for authenticating a user with arelying party using visual graphical barcode.

FIG. 12 illustrates an exemplary method for authenticating a user with arelying party.

FIG. 13 schematically illustrates an exemplary system implementing anidentity proofing and authentication method.

FIG. 14 illustrates an exemplary method for authenticating a user with afinancial institution.

FIG. 15 shows an example of performing authentication for a transactionvia a TV.

DETAILED DESCRIPTION

While various embodiments of the invention have been shown and describedherein, it will be obvious to those skilled in the art that suchembodiments are provided by way of example only. Numerous variations,changes, and substitutions may occur to those skilled in the art withoutdeparting from the invention. It should be understood that variousalternatives to the embodiments of the invention described herein may beemployed.

The term “user,” as used herein, generally refers to an individual orentity that is capable of opening an online account with an onlineservice provider.

The term “online service provider,” as used herein, generally refers toservice providers that have an online portal or an online webpagethrough which users can open an online account. The term “serviceprovider,” herein, may be used interchangeably with “online serviceprovider.”

The term “online account,” as used herein, generally refers to adistinct account that can be created online by a user. An online accountcan be dedicated to, and/or owned by, a user. User-specific information(e.g., name, address, email, etc.) can be associated with a user'sonline account. Accordingly, online service providers can identify usersby a user's online account with the online service provider. Access toan online account can be protected by associating user credentials, suchas a username and accompanying password, of the user to the onlineaccount and requiring provision of the user credentials when a userrequests access to the online account. Online accounts can be stored ina memory storage of a server (such as a server 201 in FIG. 2).

The term “registered,” as used herein, generally refers to the state ofhaving opened an online account with an online service provider. Forexample, a user can be registered to an online service provider if theuser has created an online account with the online service provider.

A user may wish to open an online account with an online serviceprovider for any number of reasons including, for example, to preserveand track a relationship between the user and the online serviceprovider (e.g., financial institutions, educational institutions, etc.),to save frequently used user information (e.g., shipping address) or ahistory of user activities (e.g., order invoices) with the onlineservice provider (e.g., online retailer), to avoid having to provideredundant information to receive a same or similar service from theonline service provider, to conveniently manage a service (e.g.,insurance claim) provided by the online service provider (e.g.,insurance company) to the user, to engage in social networking servicessupported by the online service provider (e.g., Facebook®, Instagram®),to take ownership of an online identity (e.g., email) provided by theonline service provider (e.g., Gmail®, Outlook®, etc.), and so on.

In some instances, a user may remain mostly anonymous and provideminimal information (e.g., email address, password) to open an onlineaccount. In some instances, however, opening an online account mayentail providing highly personal and sensitive user information to theonline service provider such that it may be in the user's best intereststo verify the identity of the online service provider before providingsuch user information. Similarly, an online service provider may providehighly personal and sensitive services (e.g., providing credit report,bank statement) to registered users such that it may be in the onlineservice provider's best interests to verify the identity of the userbefore providing such services.

For example, an online service provider can require a user to providepersonal information (e.g., full name, previous names, address, phonenumber, email address, social security number, etc.), employmentinformation (e.g., employer name, employer address, work email, workphone number, years of employment, etc.), financial information (e.g.,credit card number, bank name, bank account number, routing number,Paypal® account, etc.), online profile information (e.g., username,nickname, password, security question & answer, etc.), and sometimescopies of physical documents (e.g., driver's license, transcript,statement, utility bill, etc.). In some instances, an online serviceprovider may request additional verification steps to verify a user'sidentity or to verify user information (e.g., email verification viaemail code, phone number verification via text code). Oftentimes,manually completing these personal and sensitive information requestscan be cumbersome, time-consuming, and redundant for users who have toinput the same or similar user information every time they open anonline account. It can deter users from opening accounts with the onlineservice provider requesting such voluminous information. In otherinstances, the user may be providing personal and sensitive informationto a fraudulent service provider posing as an authentic serviceprovider, risking a serious identity security hazard.

Provided are methods and systems for opening an online account that can(1) verify the identity of a user to an online service provider and/orverify the identity of an online service provider to a user; and (2)supply user information required for opening an online account with anonline service provider to the online service provider, withoutrequiring the user to manually input the user information.

An authentication system can verify the identity of a user and/or anonline service provider to the other by generating and analyzinggraphical authentication indicia or quick response (QR) codes. Forexample, each online account opening process may be associated with aunique QR code. The unique QR code can be a one-time unique QR code. Aone-time unique QR code may become invalid after the first use of the QRcode or, alternatively, the QR code may become invalid after passage ofa finite duration of time (e.g., 1 second, 5 seconds, 30 seconds, 1minute, 5 minutes, 10 minutes, etc.) since the QR code is generated ormade available to a user. Alternatively, a one-time unique QR code maybecome invalid after the occurrence of either of the above two events,whichever comes first. The graphical authentication indicia or QR codescan be used to mutually verify the identities between a user and anonline service provider. Alternatively, verification can be one-sidedand the user can verify the identity of an online service provider orthe online service provider can verify the identity of a user.

A user wishing to open an online account with an online service providermay send a request to the online service provider and/or anauthentication system to open an online account with the online serviceprovider. Upon receiving the request, either directly from the user orfrom the online service provider forwarding the user's request, theauthentication system may generate a one-time unique QR code and providethe QR code to the user by displaying the QR code on a display device.Alternatively, the authentication system may provide the QR code to theonline service provider, and the online service provider can provide theQR code to the user by displaying the QR code on the display device. Theuser may capture an image of the QR code provided on the display devicewith a user device and provide the image of the QR code or an analysisof the image of the QR code to the authentication system through theuser device. The authentication system may identify the image of the QRcode as associated with the online service provider and thereby verifythe identity of the online service provider to the user. Similarly, theauthentication system may identify the user device providing the imageas associated with the user, and thereby verify the identity of the userto the online service provider.

In another aspect, the authentication system may collect userinformation from a user and store the user information into a memorystorage space of the authentication system prior to the user opening anonline account. The user information collected by the authenticationsystem can include any and all information that an online serviceprovider could possibly request from a user when opening an onlineaccount with the online service provider. The memory storage space ofthe authentication system can be a database. Once the identity of a userand/or an online service provider has been verified, the authenticationsystem may identify the type (e.g., name, birth date, email, credit cardnumber, etc.) of user information required for opening an account withthe particular online service provider and supply the required userinformation of the user from the memory storage space of theauthentication system to the online service provider. The user may beallowed to approve, reject, or edit one or more type, or field, of userinformation to be provided to the online service provider before theuser information is submitted. Accordingly, the user may open an onlineaccount with an online service provider with less, or minimal, manualinput of user information.

As previously mentioned, in some situations, users and online serviceproviders may need to verify the identity of the other before proceedingwith an account opening process. A visual graphical barcode such as a QRcode may be employed to verify the respective identities and/orestablish a secured communication between a user and an online serviceprovider.

FIG. 1 shows a schematic illustration of a user device 104 capturing agraphical barcode in accordance with an authentication session. Theauthentication session may be hosted by a server (such as the server 201of FIG. 2) on one or more interactive webpages, and accessed by one ormore users. The user device 104 can be used to scan a visual graphicalbarcode such as a QR code displayed on a display device 101. The QRcode, or any other visual graphical barcodes, can be provided to thedisplay device 101 by an authentication system 102. The user device 104and the display device 101 may be separate devices. Alternatively, theuser device 104 and the display device 101 may be the same device. Forexample, a QR code can be displayed on the display screen of the userdevice 104. The user device 104 can be registered with theauthentication system 102.

The user device 104 may be a mobile device (e.g., smartphone, tablet,pager, personal digital assistant (PDA)), a computer (e.g., laptopcomputer, desktop computer, server), or a wearable device (e.g.,smartwatches). A user device can also include any other media contentplayer, for example, a set-top box, a television set, a video gamesystem, or any electronic device capable of providing or rendering data.The user device may optionally be portable. The user device may behandheld. The user device may be a network device capable of connectingto a network, such as a local area network (LAN), wide area network(WAN) such as the Internet, a telecommunications network, a datanetwork, or any other type of network.

The user device 104 may comprise memory storage units which may comprisenon-transitory computer readable medium comprising code, logic, orinstructions for performing one or more steps. The user device maycomprise one or more processors capable of executing one or more steps,for instance in accordance with the non-transitory computer readablemedia. The user device may comprise a display showing a graphical userinterface. The user device may be capable of accepting inputs via a userinteractive device. Examples of such user interactive devices mayinclude a keyboard, button, mouse, touchscreen, touchpad, joystick,trackball, camera, microphone, motion sensor, heat sensor, inertialsensor, or any other type of user interactive device. The user devicemay be capable of executing software or applications provided by one ormore authentication systems. One or more applications may or may not berelated to reading codes such as graphical barcodes.

In some instances, the software and/or applications may allow the userto scan graphical authentication indicia such as a QR code displayed onanother device or the same device, and transmit authentication databetween the user device 104 and the authentication system 102 during anauthentication session. The software and/or application may have beenregistered with the authentication system by the user. Optionally, thesoftware and/or application need not be registered with theauthentication system, and only the user device may be registered withthe authentication system. Optionally, both the software and the userdevice can be registered with the authentication system. Optionally, thesoftware and/or application may be configured to collect authenticationdata (e.g., image capture characteristics, time of capture, etc), andencrypt the data before sending them to the authentication server (suchas the server 201 in FIG. 2) during an authentication session.

The user device 104 may be, for example, one or more computing devicesconfigured to perform one or more operations consistent with thedisclosed embodiments. The user device may be capable of opticallydetecting one or more visual element, such as a visual code. The userdevice may utilize an optical detection apparatus. The optical detectionapparatus may optically read or scan a visual element. In someembodiments, the user device may comprise an imaging device 103 which isconfigured to capture a visual graphical element, such as a bar code(e.g., one-dimensional, two-dimensional), text, a picture, a sequencethereof, or any other forms of graphical authentication indicia that isbeing displayed on display device 101. The imaging device can include ahardware and/or software element. In some embodiments, the imagingdevice may be a hardware camera sensor operably coupled to the userdevice. For example, the camera sensor can be embedded in the userdevice. Alternatively, the imaging device may be located external to theuser device, such as connected via cable or wirelessly, and image dataof the graphical element may be transmitted to the user device viacommunication means as described elsewhere herein. The imaging devicecan be controlled by applications and/or software configured to scan avisual graphical code. For example, the camera may be configured to scana QR code. Optionally, the software and/or applications may beconfigured to activate the camera on the user device to scan the code.In some instances, the camera can be controlled by a processor nativelyembedded in the user device. Optionally, if the display device 101 andthe user device 104 are the same device, the imaging device can comprisea screen capturing software (e.g., screenshot) that can be configured tocapture and/or scan a QR code on the screen of the user device 104.

The display device 101 may be configured to display a visual graphicalcode (e.g. a QR code) to the user. In some embodiments, the QR code maybe displayed via an interface such as a webpage, application, program,or any appropriate software. The display device 101 can be a monitor, acomputer (e.g., laptop computer, desktop computer), a mobile device(e.g., smartphone, tablet, pager, personal digital assistant (PDA)), avending machine. In some instances, the display device may comprise oneor more processors natively embedded in the display device. The displaydevice may optionally be portable. The display device may be handheld.

In some instances, the visual graphical code displayed on the displaydevice 101 and subsequently scanned by imaging device 103 may be a QRcode. QR codes are two-dimensional barcodes that encode data by usingdark and light modules arranged in a square-like or rectangular shape.QR codes can be optically captured and read by a machine. The barcodemay define elements such as the version, format, position, alignment,and timing of the barcode to enable reading and decoding of the barcode.The remainder of the barcode can encode various types of information inany type of suitable format, such as binary or alphanumeric information.The QR code can have various symbol sizes as long as the QR code can bescanned from a reasonable distance by an imaging device. The QR code canbe of any image file format (e.g. EPS or SVG vector graphs, PNG, TIF,GIF, or JPEG raster graphics format). The QR code can be based on any ofa number of standards. In some instances, a QR code can conform to knownstandards that can be read by standard QR readers. The informationencoded by a QR code may be made up of four standardized types (“modes”)of data (numeric, alphanumeric, byte/binary, kanji) or, throughsupported extensions, virtually any type of data. In some instances, theQR code may be proprietary such that it can be read only by anauthenticated application, provided by the authentication system,running on a user device. In some instances, only the authenticationsystem or the authenticated application can encrypt or decrypt the QRcode.

FIG. 2 shows a schematic diagram of users and online service providersusing the authentication system to verify the identities of the usersand/or the online service providers. A server 201, at the command of auser or an online service provider, may submit a QR code request to anauthentication system 203. A server, as the term is used herein, mayrefer generally to a multi-user computer that provides a service (e.g.online transaction, database access, file transfer, remote access) orresources (e.g. file space) over a network connection. The server 201may be provided or administered by an online service provider. In somecases, the server may be provided or administered by a third partyentity in connection with a device provider. The one or more servers 201may or may not be registered with the authentication system 203. In someinstances, the server may include a web server, an enterprise server, orany other type of computer server, and can be computer-programmed toaccept requests (e.g., HTTP, or other protocols that can initiate datatransmission) from a computing device (e.g., a user device, a publicshare device) and to serve the computing device with requested data. Inaddition, the server can be a broadcasting facility, such asfree-to-air, cable, satellite, and other broadcasting facility, fordistributing data. The server may also be a server in a data network(e.g., a cloud computing network). In some embodiments, the onlineservice provider 215 may administer one or more servers 201 to providevarious services to the user 217, such as allowing users to create anonline account with the online service provider.

The QR code request may be initiated when a user 217 initiates anaccount opening process. For example, when a user accesses a webpageportal provided by an online service provider 215 to open an accountwith the online service provider, such as by pressing a “register” or“sign up” button on a website of the online service provider, the onlineservice provider may request a QR code from the authentication system203. Alternatively, the user may directly request a QR code from theauthentication system, such as by initiating the account opening processwith a particular online service provider through an application and/orsoftware provided by the authentication system or through a webpageportal or website hosted by a server of the authentication system. Theuser may access the webpage portal using, for example, the user device104 and/or the display device 101 in FIG. 1. The server 201 may send therequest to the authentication system for a QR code.

The authentication system 203 may generate a QR code associated with therequest by the server 201 after verifying the identity of the onlineservice provider 215. The request may contain an identity of the onlineservice provider and a session ID. In some instances, the online serviceprovider may have been previously registered with the authenticationsystem and the verified identity of the online service provider may bestored in a database accessible to the authentication system (such as adatabase 312 of FIG. 3). Alternatively or in addition to verifying theidentity, the authentication system may determine whether the QR coderequest came from a trusted source or entity. In some instances, theidentity of the online service provider can be designated as a trustedsource or entity by the authentication system, such as via domainaddress, registration certificate, or other forms of evidence. Upondetermining that the request came from a verified online source providerand/or an online source provider which is a trusted source or entity,the authentication system may respond to the request by sending a uniqueQR code back to the requesting server. The server may then display theQR code on the webpage portal on a display device 209 so that the codecan be displayed to the user 217.

When the authentication system 203 receives the QR code request from theserver 201, a QR code generator 205 in the authentication system maygenerate a unique code along with a validation ID and a locator of theunique code. In some instances, the unique code may be a QR code inwhich the validation ID is encrypted. Generating a QR code may compriseat least three steps: (1) generating a unique validation ID, (2)encrypting the validation ID into an encrypted message, and (3)generating a one-time QR code encoding the encrypted message. Thevalidation ID may be unique to each online account opening session. Insome instances, the validation ID may be associated with a serveridentity, a service provider ID, a session ID, and/or a timestamp. Theserver identity and/or service provider ID may be known only to theauthentication system. The session ID may be provided by the requestfrom the server. In some instances, the timestamp may be in the formatof ‘yyyyMMddHHmmss’ or any other suitable format if specified in therequest. The validation ID can be used to identify the authentication(QR code) request in a unique manner. The validation ID or associated QRcode may expire after a certain period of time or once they have beenvalidated.

The validation ID may be encrypted by any suitable cryptographictechniques. The validation ID can comprise any format and data type. Forexample, symmetric-key algorithms may be used for encryption anddecryption. The keys can be composed from a sentence or a series ofnon-meaningful characters, and encryption can be done by performing abitwise XOR operation on data chunks (e.g., original data, structuredata and Reed-Solomon data) that compose the QR code. The QR code may begenerated by choosing a number of random locations in data and changingthe bytes in these locations randomly. The Reed-Solomon algorithm cancorrect wrongly decrypted code words and form the correct message. TheQR code can have any suitable storage capacity as long as it is capableof uniquely associating a QR code to a session. Any suitable visualgraphical code may be used to represent the unique validation ID, suchas a one-dimensional or two-dimensional code, images, and so on.

The generated QR code may be stored in a database accessible to theauthentication system 203. The authentication system may retrieve the QRcode from the database via the unique validation ID. Once the code isgenerated, a locator of the code may be provided to the server 201. Insome instances, the locator can be a link or hyperlink associated withthe code, such as a URL (uniform resource locator) to an IP (internetprotocol) address or any other form of link that can enable a user usinga browser to access the visual graphical code provided by a web serverfrom the authentication system. Alternatively, the QR code may be sentdirectly to the server 201. The session ID may be provided to the onlineservice provider along with the QR code or the locator such that theonline service provider can link the code to the specific request.

The server 201 may or may not store a copy of the code. In someinstances, the server may only store the locator, whereas the graphicalimage code can be stored in a database of the authentication system 203.Allocating the storage of the graphical image code to the database ofthe authentication system may beneficially ease the burden of the server201 in terms of memory space. Once the QR code or locator is received,the server 201 may send the QR code or locator to a display device 209configured to display the webpage portal of the online service provider215. In some instances, the display device 209 in FIG. 2 may correspondto the device 101 in FIG. 1. As previously mentioned, in some instances,the display device 209 may or may not be registered with theauthentication system 203. For example, the display device may be apublicly shared device. The display device 209 may be configured to beable to display an image such as a QR code. Optionally, the displaydevice may prompt the user to scan the QR code via a message on thescreen (e.g., “Please scan the QR code,” “Please take a picture of theQR code,” etc.).

A user 217 may use an imaging device 211 to scan the QR code displayedon the display device 209. In some instances, the imaging device 211 inFIG. 2 may correspond to the imaging device 103 in FIG. 1. In someinstances, the user device (e.g., user device 104 in FIG. 1) maycomprise the imaging device. The imaging device may be configured tocapture an image of the QR code. Alternatively, the imaging device maybe located on an external device such as an external camera sensorcommunicatively coupled (e.g., cables, wireless connection) to the userdevice. The captured visual graphical code may be transmitted to theuser device via communication means such as cable or wirelessconnection. Optionally, the user device may comprise both the imagingdevice 211 and the display device 209, wherein the user may capture a QRcode displayed on the display screen of the user device using an imagingmechanism (e.g., screen capture). The imaging device can be controlledby an application/software to scan a visual graphical code.

The captured visual graphical code can be transmitted from the userdevice (e.g., user device 104 in FIG. 1) to a QR code analyzer 207 inthe authentication system 203 for analysis. In some instances, the QRcode may be transmitted to the code analyzer via an application orsoftware. The application or software may be provided by theauthentication system 203 and run on the user device. In some instances,the image data of the QR code may be directly sent to the QR codeanalyzer (e.g., in image format). Alternatively, the application orsoftware may process the captured code (e.g. decode the code or decryptthe decoded data) and send the processed information to the QR codeanalyzer for analysis. Optionally, the identity of the user device maybe transmitted along with the code or processed information as a datapacket to the authentication system 203.

The authentication system 203 may analyze the QR code for identificationof the user 217 and/or verification of the online service provider 215.The QR code analyzer 207 may receive the code from the user device anddecode the QR code and/or decrypt the decoded data. In some instances,the QR code analyzer may verify that the captured QR code is associatedwith a request from an authenticated online service provider, based onthe validation ID encrypted in the code. Optionally, the QR codeanalyzer may provide the identity of the verified online serviceprovider to the user to prevent fraudulent phishing attacks. Forexample, if the validation ID encrypted in a captured QR code does notmatch any record of a validation ID generated by the QR code generator205 of the authentication system 203, then the lack of match canindicate a phishing attack. The authentication system may notify theuser that the QR code is foreign to the authentication system, alertingthe user of the possibility that the online service provider whichprovided the particular QR code to the user may be unverified and/orposing as an authenticated online service provider. In another example,if the validation ID is expired, wherein the authentication systemdetermines that the validation ID has been previously validated by theuser or another user or the validation ID contains a timestamp earlierthan the timestamp in the stored copy of the QR code in the systemdatabase, then the expiration may indicate a replay attack. A user maybe subject to a replay attack when an online service provider provides,or re-uses, an expired QR code without going through the authenticationsystem (e.g., sending a new request for a code) and without the user'sknowledge or approval. The authentication system may send a fraud alertto the user device, and prevent the user from proceeding with opening anaccount with the online service provider. In another example, theauthentication system may determine that the validation ID is valid andthat the identity of the online service provider is verified but thatthe online service provider is not registered as a trusted entity orsource with the authentication system. The authentication system maysend a warning to the user that the particular online service provideris not a trusted entity or source.

Alternatively or in addition, the QR code analyzer 207 may analyze thecollected data packet to identify the user device and/or the user 217.The user device may be pre-registered as an authenticated device of theuser with the authentication system 203 via an application or softwareprovided by the authentication system. Alternatively, the user maymanually register the user device by inputting and verifying a uniquedevice identifier (e.g., IMEI code, serial number, etc.) to theauthentication system and associating the user device with the user. Theidentity of the authenticated user device may comprise a unique userdevice ID which may be pre-existing with the user device (e.g., IMEIcode, serial number, etc.) or generated by the authentication system andassociated with the user device upon registration of the user devicewith the authentication system. The user device identity data may bestored in a database accessible by the authentication system. For eachcaptured QR code, a user device may transmit the captured QR code dataas well as user device identity data to the QR code analyzer.Subsequently, the authentication system may store the user deviceidentity data as associated with the QR code in the system database forfuture user authentication and/or comparison with a stored useridentity. For example, the authentication system may identify that auser device, and thereby the user, has already opened an online accountwith the online service provider that the user is presently attemptingto register with. The authentication system may inform the onlineservice provider that the user is creating a second, third, or n^(th)account. An online service provider offering special services (e.g.,discount codes) to first time registering users (e.g., customers) maybeneficially avoid providing the special services to the repeating user.Similarly, an online service provider allowing only one online accountper user may deny a user who has already created an account fromcreating a second account. Alternatively or in addition, theauthentication system may inform, or remind, the user that the user hasalready created an online account with the online service provider.Optionally, the authentication system may provide the user withinformation regarding the pre-existing online account (e.g., username,email, etc.) to help the user access the pre-existing online account. Inanother example, the authentication system may inform the online serviceprovider that the user is a verified user of the authentication system.

Once the authentication session is completed, the user and the onlineservice provider may proceed with the account opening process, includingrequesting and receiving user information, which will be described inmore detail further below.

FIG. 3 shows examples of user information data 300 that may be storedfor each user and/or each user device. A user may be registered with theauthentication system. For example, the user may be a registered user toan entity (e.g., a company, an organization, an individual, etc.) thatprovides, and/or administers, one or more authentication systems (suchas the authentication system 203 of FIG. 2). Users may include anyindividuals or groups of individuals using software or applicationsprovided by the authentication system. For example, the users may accessa user device or a web account using an application programmableinterface (API) provided by the authentication system. A user may beassociated with one or more user devices. Alternatively or in addition,a user device may be associated with one or more users. In an example,if more than one user can be associated with a user device, the softwareor applications provided by the authentication system can require a userto identify the user by inputting user credentials (e.g., loginusername, password, PIN, fingerprint, etc.). In another example, if morethan one user device can be associated with a user, a user may have afirst user device (e.g., mobile phone) and a second user device (e.g.,desktop computer) associated with the user at any point in time. Theusers may be located geographically at a same location, such as usersworking in a same office or a same geographical location. In someinstances, some or all of the users and user devices may be at remotegeographical locations (e.g., different cities, countries, etc.),although this is not a limitation of the invention.

Upon registration with the authentication system, the user may beassigned a unique user ID (e.g., “UID 1” in FIG. 3). The user ID may begenerated by the authentication system or provided by the user (e.g.,username, login ID, nickname, email, etc.). The user ID may be in anyformat and can be stored in a database accessible to the authenticationsystem (such as the database 512 in FIG. 5). The user may register oneor more user devices as associated to the user in the authenticationsystem. For example, if a user used a first user device (e.g., mobilephone, tablet, desktop computer) to register with the authenticationsystem, such as by installing a dedicated software or applicationprovided by the authentication system on the user device or creating aweb account through the user device, the authentication system mayautomatically associate the first user device with the user.Alternatively, the authentication system may allow a user to decide toassociate the first user device with the user. Optionally, the user mayassociate a user device or additional user devices with the user bymanually inputting and verifying a unique device identifier (e.g., IMEIcode, serial number, etc.) of the user device to the authenticationsystem and associating the user device with the user.

Each user device may be assigned a unique user device ID (e.g., “UDID 1”in FIG. 3). The user device ID may be generated by the authenticationsystem or be taken from the user device (e.g., IMEI code, serial number,etc.). The user device ID may be in any format and can be stored in adatabase accessible to the authentication system (such as the database512 in FIG. 5). Each user device ID may be stored as associated with oneor more user IDs in a database. Similarly, each user ID may be stored asassociated with one or more user device IDs in a database. Associationmay be represented by rows in a database (as in FIG. 3), wherein thedatabase comprises a column for a user ID and another column for a userdevice ID. Alternatively, association may be represented by columns in adatabase, wherein the database comprises a row for a user ID and anotherrow for a user device ID. For example, in FIG. 3, each row representsassociated data, wherein a first user ID, UID 1, is associated with afirst user device ID, UDID 1, a second user ID, UID 2, is associatedwith a second user device ID, UDID 2, and so on. In another example, notshown in FIG. 3, a first user ID, UID 1, may be associated with two userdevice IDs, UDID 1 and UDID 2, in two separate rows with repeating userIDs. Alternatively, also not shown in FIG. 3, the database may comprisea column for a user ID, another column for a first user device ID,another column for a second user device ID, and so on, such that thereis only one row for each user ID. Alternatively, if more than one userIDs are associated with one user device ID, the database may comprise acolumn for a user device ID, another column for a first user ID, anothercolumn for a second user ID, and so on, such that there is only one rowfor each user device ID.

The authentication system may collect user information data for eachuser ID and/or user device ID. The user information data may all bestored together in a single memory unit or may be distributed overmultiple memory units. Data distributed over multiple memory units mayor may not be simultaneously accessible or linked. Similarly, data canbe distributed over multiple databases that may or may not besimultaneously accessible or linked. The data may include data collectedfor a single user for multiple user devices, for a single user for asingle user device, or for a single user device for multiple users. Datafrom multiple users for a single user device may all be stored togetheror may be stored separately from one another. Data from multiple userdevices for a single user may all be stored together or may be storedseparately from one another. In some instances, all units of userinformation data collected for each user ID may be stored in a singlerow or a single column in a database. In other instances, all units ofuser information data collected for each user device ID may be stored ina single row or a single column in a database. Alternatively, differentunits of user information data may be stored in different databases.Alternatively or in addition, different user IDs and/or different userdevice IDs may be stored in different databases.

The user information data 300 collected by the authentication system caninclude any and all information that an online service provider couldpossibly request from a user when the user is opening an online accountwith the online service provider. Such information can include, forexample, personal background information (e.g., first name, middle name,last name, previous names, present address, mailing address, previousaddresses, primary phone number, secondary phone number, home phonenumber, mobile phone number, primary email address, secondary emailaddress, social security number, birth date, title, high school,college, graduate school, highest education degree received, year ofeducational institution attendance, year diploma awarded, etc.),employment information (e.g., employer name, employer address, workemail, work phone number, years of employment, reference name, referencephone number, reference email, etc.), financial information (e.g.,credit card number, credit card expiration date, credit card securitycode, bank name, bank account number, routing number, Paypal® accountusername, annual or monthly income, amount of loans, etc.), onlineprofile information (e.g., username, nickname, password, first securityquestion & answer, second security question & answer, etc.), andsometimes copies (e.g., scanned copies, photographs, images, etc.) ofphysical documents (e.g., driver's license, transcript, bank statement,income statement, loan statement, education diploma, utility bill, etc.)among a myriad of other information that can be required from a user.

Each ‘category’ of user information data (e.g., first name, middle name,last name, birth date year, birth date month, birth date day, streetaddress, state address state, city address, country address, address zipcode, etc.) may be stored as a separate column (as in FIG. 3) in thedatabase, wherein each row represents association of user informationdata (e.g., “UID 1” with “UDID 1” with “UI1-1” with “UI2-1” with “UIx−1”and so on in FIG. 3). Alternatively, each column can representassociation of user information data and each category of userinformation data can be stored as a row. The category of userinformation data may be of any broadness (e.g., full name) or narrowness(e.g., first name, middle name, middle initial, last name) as can berequired by an online service provider when a user requests to open anonline account. One category may be a subset of another category. Aparent category (e.g., mailing address) and a child category (e.g., zipcode, street address, state, etc.) may each comprise separate columns,or rows, in the system database.

Upon registration with the authentication system, a user may be promptedto input user information data for selected categories, such as thecategories listed above. In some instances, the authentication systemmay present a user with all the possible categories. A user may or maynot input information for all the categories presented. For example, theauthentication system may present the user with 1, 2, 3, 4, 5, 10, 20,30, 50, 100, 200, 500 categories, or fields of user input, to populateand the user may decide to selectively input information for onlycertain categories. In making the selection, for example, the user maymake an educated guess as to what type of information the online serviceproviders that the user will likely want to create an online accountwith will require.

In some instances, the authentication system may group the categories,such as into simple personal background information, detailed personalbackground information, simple financial information, detailed financialinformation, simple employment information, detailed employmentinformation, simple online profile information, detailed online profileinformation, and so on. Based on the type of online service providers auser is likely to create an online account with, the authenticationsystem may include or exclude the groups of information categories. Theuser may provide the authentication system with the types of onlineservice providers the user is likely to create an online account with(e.g., email service providers, game service providers, banking serviceproviders, delivery service providers, etc.). For example, a user whohas indicated that the user is not likely to create an online accountwith banking service providers (e.g., Bank of America®, Chase®, etc.),may not be asked to provide any type of financial information.

In some instances, the authentication system may request the user toprovide online profile information (e.g., username, nickname, password,first security question & answer, second security question & answer,etc.) in anticipation of creating an online account. For example, theuser may be asked to provide a preferred username, a preferred email ID,and a preferred password that the user would like to apply to futureonline accounts. The authentication system may prompt the user to inputa username and/or a password that meets the requirements (e.g., at leastone special character, at least 8 characters, less than 16 characters,at least one capital letter, etc.) of most online service providers. Inanother example, the authentication system may present the user with anynumber of commonly asked security questions (e.g., “What is yourmother's maiden name?”) in anticipation of an online service providerasking the question to a user when creating an online account. Inanother example, the authentication system may request that a usercreate a custom security question and a corresponding answer to thesecurity question. In some instances, the authentication system mayrequest the user to provide copies (e.g., scanned copies, photographs,images, etc.) of physical documents (e.g., driver's license, transcript,bank statement, income statement, loan statement, education diploma,utility bill, etc.). The user may provide such copies by uploading anelectronic copy to the authentication system (or server), emailing anelectronic copy to the authentication system (or server), mailing orfaxing hard copies to an administrator of the authentication system whocan translate the hard copy into an electronic copy, and so on. A usermay decide not to provide select, or any, user information to theauthentication system.

Each category of user information data may be associated with a user IDand/or user device ID of the user and stored in a database accessible tothe authentication system. The system may retrieve user information datavia a user ID and/or user device ID. The data may be encrypted beforestorage in the database for security.

An online service provider may be registered with the authenticationsystem, in a similar manner to a user being registered with theauthentication system. For example, the online service provider may be aregistered user to an entity (e.g., a company, an organization, anindividual, etc.) that provides, and/or administers, one or moreauthentication systems (such as the authentication system 203 of FIG.2). An online service provider may be associated with one or more serveridentities, which was previously discussed. Alternatively or inaddition, a server identity may be associated with one or more onlineservice providers. In an example, if more than one online serviceproviders can be associated with a server identity, the authenticationsystem may request the online service provider to provide additionalidentifying information. In another example, if more than one serveridentities can be associated with an online service provider, an onlineservice provider may have a first server identity and a second serveridentity associated with the online service provider at any point intime.

Upon registration with the authentication system, the online serviceprovider may be assigned a unique service provider ID. The uniqueservice provider ID may be generated by the authentication system orprovided by the online service provider (e.g., domain address, etc.).The service provider ID may be in any format and can be stored in adatabase accessible to the authentication system (such as the database512 in FIG. 5). The service provider database may be the same databaseas the one or more databases for user information (as in FIG. 3).Alternatively, the service provider database may be a differentdatabase. The online service provider may register one or more serversas associated to the online service provider in the authenticationsystem.

Each server may be assigned a unique server identity. The serveridentity may be generated by the authentication system or be taken fromcharacteristics of the server (e.g., server address, etc.). The serveridentity may be in any format and can be stored in a database accessibleto the authentication system. Each server identity may be stored asassociated with one or more server provider IDs in a database.Similarly, each service provider ID may be stored as associated with oneor more server identities in a database. Association may be representedby rows in a database, wherein the database comprises a column for aservice provider ID and another column for a server identity.Alternatively, association may be represented by columns in a database,wherein the database comprises a row for service provider ID and anotherrow for server identity. In another example, a first service provider IDmay be associated with two server identities in two separate rows withrepeating service provider IDs. Alternatively, the database may comprisea column for a service provider ID, another column for a first serveridentity, another column for a second server identity, and so on, suchthat there is only one row for each service provider ID. Alternatively,if more than one service provider IDs are associated with one serveridentity, the database may comprise a column for a server identity,another column for a first service provider ID, another column for asecond service provider ID, and so on, such that there is only one rowfor each server identity.

The authentication system may collect user information requirement datafor each service provider ID and/or server identity. The userinformation data and the user information requirement data may all bestored together in a single memory unit or may be distributed overmultiple memory units. Data distributed over multiple memory units mayor may not be simultaneously accessible or linked. Similarly, data canbe distributed over multiple databases that may or may not besimultaneously accessible or linked.

The user information requirement data may represent the categories ofuser information an online service provider requests from a user whenthe user is creating an online account with the online service provider.For example, an online service provider that is a banking serviceprovider may request that a user wishing to create an online accountprovide information such as: first name, middle name, last name, address(e.g., street, apartment number, city, state, zip code), phone number,email address, social security number, birth date, annual income, choiceof security question 1, answer to security question 1, choice ofsecurity question 2, answer to security question 2, choice of securityquestion 3, answer to security question 3, username, and password. Theuser information requirement data for the online service provider maycomprise all of the above listed categories. As can be seen from thisexample, user information requirement data for each service provider IDand/or server identity may comprise a selection of user informationcategories. In some instances, the authentication system may store theuser information requirement data for an online service provider as alist, or a collection, of selected user information categories.Alternatively, the authentication system may store the user informationrequirement data for an online service provider as binary information(e.g., T/F, 0/1) for each category, which can save memory space.

The online service providers may provide the user informationrequirement data manually to the authentication system. Alternatively orin addition, the authentication system may, through pre-programmedinstructions, extract the user information requirement data from the webportal or website of the online service providers (e.g., via analyzingsource code) and automatically recognize certain user informationcategories. Different online service providers may label a userinformation category differently (e.g., “name” vs. “full name”;“resident address” vs. “mailing address” vs. “primary address” vs. “homeaddress”; “mobile phone” vs. “primary phone” vs. “home phone” vs. “phonenumber” vs. “phone”, etc.). The authentication system may consolidatedifferent labels indicating the same user information category such asto ensure that the user information requirement data can match withexisting user information categories. In some instances, theauthentication system may consolidate labels by pre-programmingsynonyms, or frequently interchanging labels (e.g., “phone number” vs.“phone” vs. “phone no.” vs. “home phone”, etc.), to appear as one userinformation category.

FIG. 4 shows a flow diagram of the authentication system providing userinformation to an online service provider. Upon initiation by a user tocreate an online account 402 with an online service provider, and afterthe authentication system validates the identity of the user to theonline service provider and/or the identity of the online serviceprovider to the user such as by generating and analyzing a graphicalcode such as a QR code 404, the authentication system may retrieve fromone or more databases the user information requirement data for theonline service provider 406. Upon identifying the required userinformation categories from the user information requirement data forthe online service provider 408, the authentication system may, next,retrieve user information for the selected categories 410 and providethe selected user information to the online service provider 412.

In some instances, the authentication system may provide the userinformation to the online service provider (such as through server 201in FIG. 2) by automatically populating requested user information fields(e.g., populating the brackets in “First name: Panel”; “Last name:[Doe]”; “Address: [### Alphabet St, Alpha City, Beta State, GammaCountry, #####]”; “Birth date: [MM/DD/YYYY]”; “Phone number:[(###)###-####]”; “Social security number: [#########]”, etc.). The usermay be presented with the requested, and subsequently populated, userinformation fields, such as on a display device 209 in FIG. 2, to editone or more units of user information as necessary before submitting theinformation to the online service provider. In some instances, if a useradds user information to a user information category that was previouslyunpopulated because the authentication system lacked user informationfor the user information category, the authentication system may collectand store the user information for the user information category forfuture use (e.g., for other online account opening sessions). In someinstances, if a user edits user information for a user informationcategory before submitting to the online service provider, theauthentication system may collect and store the edited user informationfor the user information category and overwrite the pre-edit userinformation. The new or edited user information may be submitted to theauthentication system directly to the authentication system or throughthe online service provider, such as through server 201 in FIG. 2. Theuser may be presented with an option to provide the new or edited userinformation to the authentication system or to prevent theauthentication system from storing the new user information.Alternatively, the authentication system may automatically collect anyand all new or edited user information without asking for userpermission. The authentication system may associate the user informationto a user ID and/or a user device ID based on the validation ID for theauthentication session. Once the user submits the provided userinformation to the online service provider, such as through a userdevice 104 and/or display device 101 in FIG. 1, and the online serviceprovider confirms receipt of the information without any error, theonline account opening session can terminate.

Alternatively, the authentication system may submit the user informationdirectly to the online service provider without presenting the userinformation to the user first, and the online service provider canconfirm receipt of the user information, thereby completing the onlineaccount opening session. The authentication system may ask the user onlyfor additional user information for which the authentication systemlacks in its database.

In some instances, the authentication system may require a user toprovide at least some online profile information (e.g., username,password) for each online account opening session. A user maybeneficially secure the user's account from being breached bydifferentiating such information.

In some instances, before providing the user information to the onlineservice provider, either in populating the user information fields orproviding the user information to the online service provider directly,the authentication system may obtain permission from the user.Alternatively or in addition, the authentication system may allow a userto decide whether to preview the user information (e.g., as populateduser information fields) or to provide the user information to theonline service provider directly.

FIG. 5 illustrates an exemplary network layout comprising one or moreauthentication systems, in accordance with some embodiments. In oneaspect, the network layout may include a plurality of user devices 502,one or more servers 504, a network 506, one or more databases 512, aplurality of display devices 514, a plurality of authentication servers508, and one or more authentication systems 510. Each of the components502, 504, 508, 510 and 514 may be operatively connected to one anothervia a network 506 or any other type of communication link that allowsthe transmission of data from one component to another.

A user device 502, as described previously herein, can be, for example,one or more computing devices configured to perform one or moreoperations consistent with the disclosed embodiments. For example, auser device may be a computing device that is capable of executingsoftware or applications provided by the one or more authenticationsystems 510. In some embodiments, the software and/or applications mayenable the user to scan a QR code or a visual graphical barcodedisplayed on another device, process the QR code or visual graphicalbarcode, and transmit authentication data between the user device andthe authentication system during an authentication session. The softwareand/or application may have been registered with the authenticationsystem by user. Optionally, the software and/or application may not beregistered with the authentication system, and the user device can beregistered with the authentication system. As such, the user may or maynot be required to login to the user's account with the authenticationsystem in order to proceed with the authentication session. In someembodiments, the application may be configured to collect authenticationdata (e.g., image capture, capture time, etc), and encrypt the databefore sending them to the authentication server during anauthentication session. The authentication session may be hosted by theserver 504 on one or more interactive webpages, and accessed by one ormore users.

As described previously, the user device 502 may comprise an imagingdevice such as a camera and/or an imaging software. The camera and/orimaging software may be configured to be able to capture a QR code or avisual graphical barcode.

In some instances, the network 506 may comprise a plurality of userdevices 502. Each user device may be associated with one or more users.The one or more users may be located geographically at a same location,for example users working in a same office or a same geographicallocation. In some instances, some or all of the users and user devicesmay be at remote geographical locations (e.g., different cities,countries, etc.), although this is not a limitation of the invention.

The network layout may comprise a plurality of nodes. A node may be partof a telecommunications network. A node may receive and/or relayinformation. A node may generate information that may be relayed. Eachuser device 502 in the network may correspond to a node. In FIG. 5, if a“user device 502” is followed by a number or a letter, it means that the“user device 502” may correspond to a node sharing the same number orletter and other components corresponding to the node. For example, asshown in FIG. 5, user device 502-1 may correspond to node 1 which isassociated with user 1, display device 514-1, and server 504-1; userdevice 502-2 may correspond to node 2 which is associated with user 2,display device 514-2, and server 504-2; and user device 502-k maycorrespond to node k which is associated with user k, display device514-k, and server 504-k, where k may be any positive integer.

A node may be a logically independent entity in the network layout.Therefore, the plurality of nodes in the network layout can representdifferent entities. For example, each node may be associated with auser, a group of users, or groups of users. For example, a node maycorrespond to an individual entity (e.g., an individual). In anotherexample, a node may correspond to multiple entities (e.g., a group ofindividuals).

A user may be registered or associated with the authentication system.For example, the user may be a registered user of an entity (e.g., acompany, an organization, an individual, etc.) that provides, and/oradministers, one or more of authentication servers 508, databases 512,and/or authentication systems 510 for user authentication and userinformation provision consistent with certain disclosed embodiments. Oneuser may be associated with one or more user devices 502. One onlineservice provider may be associated with one or more servers 504. Thedisclosed embodiments are not limited to any specific relationships oraffiliations between the users and the online service providers orservers 504, databases 512, authentication servers 508, andauthentication systems 510.

A user device 502 may be configured to receive input from one or moreusers. A user may provide an input to a user device using an inputdevice such as, for example, a keyboard, a mouse, a touch-screen panel,voice recognition and/or dictation software or any combination of theabove. Examples of other user interactive devices may include a button,touchpad, joystick, trackball, camera, microphone, motion sensor, heatsensor, inertial sensor, or any other type of user interactive device.The input may include a user performing various virtual actions duringan authentication session or before an authentication session. The inputmay include, for example, a user selecting an online service provider toopen an online account with. The input may also include, for example, auser login to an account of the application provided by theauthentication system or entering additional user information tocomplete an account opening session.

In the illustration of FIG. 5, two-way data transfer capability may beprovided between any two components, including the authentication server508 and each user device 502, the server 504 and each user device 502,the authentication server 508 and each server 504, the server 504 andeach display device 514, etc.

An authentication server 508 may comprise one or more server computersconfigured to perform one or more operations consistent with disclosedembodiments. In one aspect, an authentication server may be implementedas a single computer through which a user device 502 is able tocommunicate with other components of the network 506. In some instances,a user device may communicate with the authentication server through thenetwork. In other instances, the authentication server may communicateon behalf of a user device with the one or more authentication systems510 or the database 512 through the network. In one aspect, theauthentication server may embody the functionality of one or moreauthentication systems. In another aspect, the one or moreauthentication systems may be implemented inside and/or outside of theauthentication server. For example, the one or more authenticationsystems may comprise software and/or hardware components included withthe authentication server or remote from the authentication server. Anauthentication server may also be a server in a data network (e.g., acloud computing network).

In some instances, a user device 502 may be directly connected to theauthentication server 508 through a separate link (not shown in FIG. 5).In certain instances, the authentication server may be configured tooperate as a front-end device configured to provide access to one ormore authentication systems 510 consistent with certain disclosedembodiments. The authentication server may, in some instances, utilizethe one or more authentication systems to process data provided by auser device (e.g., QR code image or image data) in order to compare andmatch the authentication data (e.g., timestamp, validation ID, etc.) anduser information requirement data for authentication purposes and userinformation population purposes. The authentication server may beconfigured to store the authentication data, user information data forusers, and user information requirement data for online serviceproviders in one or more databases 512. The authentication server mayalso be configured to search, retrieve, and analyze (e.g., decrypt,decode, compare, etc.) authentication data stored in the one or moredatabases. The authentication server may also be configured to search,retrieve, and store user information data and user informationrequirement data in the one or more databases.

In some instances, a user device 502 may be directly connected to aserver 504 of an online service provider to open an online account. Insome instances, the server 504 in FIG. 5 may correspond to the server201 in FIG. 2. In some instances, the server 504 may include a webserver, an enterprise server, or any other type of computer server, andcan be computer-programmed to accept requests (e.g., HTTP, or otherprotocols that can initiate data transmission) from a computing device(e.g., a user device, a public share device) and to provide thecomputing device with requested data. In addition, a server can be abroadcasting facility, such as free-to-air, cable, satellite, and otherbroadcasting facility, for distributing data. A server may also be aserver in a data network (e.g., a cloud computing network).

A server 504 may comprise known computing components, such as one ormore processors, one or more memory devices storing softwareinstructions executed by the processor(s), and data. A server can haveone or more processors and at least one memory for storing programinstructions. The one or more processors can be a single or multiplemicroprocessors, field programmable gate arrays (FPGAs), or digitalsignal processors (DSPs) capable of executing particular sets ofinstructions. Computer-readable instructions can be stored on a tangiblenon-transitory computer-readable medium, such as a flexible disk, a harddisk, a CD-ROM (compact disk-read only memory), an MO (magneto-optical),a DVD-ROM (digital versatile disk-read only memory), a DVD RAM (digitalversatile disk-random access memory), or a semiconductor memory.Alternatively, the methods disclosed herein can be implemented inhardware components or combinations of hardware and software such as,for example, ASICs (application specific integrated circuits), specialpurpose computers, or general purpose computers. While FIG. 5illustrates the authentication server 508 as a single server, in someembodiments, multiple devices may implement the functionality associatedwith the authentication server.

The network 506 may be configured to provide communication betweenvarious components of the network layout depicted in FIG. 5. The network506 may comprise one or more networks that connect devices and/orcomponents in the network layout to allow communication between thedevices and/or components. For example, the network may be implementedas the Internet, a wireless network, a wired network, a local areanetwork (LAN), a Wide Area Network (WANs), Bluetooth, Near FieldCommunication (NFC), or any other type of network that providescommunications between one or more components of the network layout. Insome embodiments, the network may be implemented using cell and/or pagernetworks, satellite, licensed radio, or a combination of licensed andunlicensed radio. The network may be wireless, wired (e.g., Ethernet),or a combination thereof.

The one or more authentication systems 510 may be implemented as one ormore computers storing instructions that, when executed by one or moreprocessors, can generate a plurality of visual graphical codes (e.g. QRcodes) upon request from a server 504 each of which is associated with aspecific session (e.g., via validation ID, session ID, etc.), andprovide the codes or locators of the codes to the server 504. Users mayscan the codes through authenticated user devices 502 and transmit thescan data back to the one or more authentication systems. The one ormore authentication systems may either, based on the codes and/or thescan data, provide user authentication to online service providers,and/or provide online service provider authentication to users for thepurpose of one-sided or mutual authentication. Upon verification, theauthentication system may provide user information of the user to theonline service provider, either through the user or directly to theonline service provider. In some instances, the server may comprise thecomputer in which the one or more authentication systems areimplemented. Alternatively, the authentication server 508 may comprisethe computer in which the one or more authentication systems areimplemented. Alternatively, the one or more authentication system may beimplemented on separate computers.

The server may access and execute the one or more authentication systemsto perform one or more processes consistent with the disclosedembodiments. In certain configurations, the one or more authenticationsystems may be a software stored in memory accessible by the server(e.g., in a memory local to the server or remote memory accessible overa communication link, such as the network). Thus, in certain aspects,the one or more authentication systems may be implemented as one or morecomputers, as software stored on a memory device accessible by theserver, or a combination thereof. For example, one authentication systemmay be a computer hardware executing one or more authenticationtechniques, and another authentication system may be software that, whenexecuted by the server, performs one or more authentication techniques.

The one or more authentication systems can be used to authenticate usersin a variety of different ways. For example, the one or moreauthentication systems may store and/or execute software that performsan algorithm for authenticating a user based on the QR code or a visualgraphical code submitted by the user device in conjunction withauthentication read data. The one or more authentication systems mayalso store and/or execute software that performs an algorithm forgenerating visual graphical codes (e.g. QR codes) having a specificvalidation ID. The one or more authentication systems may further storeand/or execute software that performs an algorithm for searching,retrieving, and storing user information for users and user informationrequirement data for online service providers.

The disclosed embodiments may be configured to implement the one or moreauthentication systems such that a variety of algorithms may beperformed to execute one or more authentication techniques andauthentication sequences, including provision of required userinformation after an authentication is complete. Although a plurality ofauthentication systems have been described for performing the abovealgorithms, it should be noted that some or all of the algorithms may beperformed using a single authentication system, consistent withdisclosed embodiments.

The user devices 502, authentication server 508, service provider server504, and the one or more authentication systems 510 may be connected orinterconnected to one or more databases 512. The one or more databasesmay be one or more memory devices configured to store data (e.g., QRcode, user identity, user device identity, service provider identity,server identity, transaction/validation ID, user information, userinformation requirement etc.). Additionally, the one or more databasesmay also, in some embodiments, be implemented as a computer system witha storage device. In one aspect, the one or more databases may be usedby components of the network layout to perform one or more operationsconsistent with the disclosed embodiments. In certain embodiments, theone or more the databases may be co-located with the server, orco-located with the authentication server, and/or co-located with oneanother on the network. One of ordinary skill will recognize that thedisclosed embodiments are not limited to the configuration and/orarrangement of the one or more databases.

A display device 512 may be an unauthenticated device in that theidentity of the device is not, and need not necessarily be, registeredwith the authentication system. In some embodiments, the device is whatthe user uses to access a web portal or website provided by the server504 to open an online account with an online service provider. Thedisplay device may be a publicly shared device whose identity is notknown to the authentication system. As described previously, the displaydevice may be configured to display a visual graphical code (e.g. QRcode) and/or user interfaces (e.g., web portal, website) to the user.The visual graphical codes or locators of the codes may be transmittedto the display device from the server. In some embodiments, when alocator (e.g., URL) is provided, the QR code may be displayed via aninterface such as a webpage or any software. The interface can be linkedto the server via the locator (e.g., URL) to establish a communicationbetween the user and the server. In other embodiments, the codeencrypted in a validation ID may be directly transmitted to the displaydevice and displayed to a user with or without an interface (e.g.,webpage, web portal, software, etc.). The display device can be acomputer (e.g., laptop computer, desktop computer), a mobile device(e.g., smartphone, tablet, pager, personal digital assistant (PDA)), avending machine or the like requiring authentication or verification ofthe user to open an online account on the server (e.g., with an onlineservice provider). The display device may optionally be portable. Thedisplay device may be handheld. The user device and the display devicefor any one node can be the same device. For example, user device 502-1may be the same device as the display device 514-1, and the user device502-2 may be the same devices as the display device 514-2.

Any of the user devices 502, the display devices 514, the servers 504,the one or more databases 512, and/or the one or more authenticationsystems 510 may, in some embodiments, be implemented as a computersystem. Additionally, while the network is shown in FIG. 5 as a“central” point for communications between components of the networklayout, the disclosed embodiments are not limited thereto. For example,one or more components of the network layout may be interconnected in avariety of ways, and may in some embodiments be directly connected to,co-located with, or remote from one another, as one of ordinary skillwill appreciate. Additionally, while some disclosed embodiments may beimplemented on the server, the disclosed embodiments are not so limited.For instance, in some embodiments, other devices (such as one or moreuser devices) may be configured to perform one or more of the processesand functionalities consistent with the disclosed embodiments, includingembodiments described with respect to the server and the authenticationsystem.

Although particular computing devices are illustrated and networksdescribed, it is to be appreciated and understood that other computingdevices and networks can be utilized without departing from the spiritand scope of the embodiments described herein. In addition, one or morecomponents of the network layout may be interconnected in a variety ofways, and may in some embodiments be directly connected to, co-locatedwith, or remote from one another, as one of ordinary skill willappreciate.

FIG. 6 illustrates a schematic block diagram of an exemplary system andmethod for opening an online account using a code. In one aspect of theinvention, an authentication system 610, server 606, and user device 602can engage in a mutual authentication process that verifies theauthenticity of both the user and the online service provider so that auser can ensure that the user is providing user information to averified online service provider and the online service provider canensure that the online service provider is opening an online account fora verified user. Alternatively, authentication can be one-sided suchthat either an online service provider is verified to a user or a useris verified to an online service provider. Servers 606 can be providedor administered by an online service provider. In some instances, theservers may be provided or administered by a third party entity. Boththe online service provider and the user may have been previouslyregistered with the authentication system 610. When the user isregistered, the authentication system may create an account containinginformation about the user identity (ID) associated with the user, oneor more user devices 602 (e.g., user device ID) associated with theuser, and user information data (e.g., personal background information,financial information, etc.) associated with the user. Such userinformation data can be stored in one or more databases that areaccessible by the authentication system. A user may or may not berequired to login with the user's account through an application orsoftware from a user device that may or may not be associated with theuser in the authentication system, whereby the application is providedby the authentication system. In some embodiments, the authenticationserver (e.g., in one or more databases accessible by the authenticationsystem) can maintain additional information such as QR code data (e.g.,raw image, image data) submitted by the user device during anauthentication session.

When a user initiates an online account opening process with an onlineservice provider, the server 606 associated with the online serviceprovider may send a request to the authentication system 610. Therequest may encode a server identity, service provider ID and/or asession ID. The authentication system 610 can decode the serveridentity, service provider ID and/or session ID in the request andgenerate a visual graphical code, such as a QR code, encoding a uniqueone-time identifier associated with the request. The unique one-timeidentifier may be a validation ID unique to the QR code which can beused for retrieving authenticating data. In some embodiments, the QRcode can be an identifier intended for one-time use which expires uponfirst use or after a finite duration of time, or whichever event occursfirst. Next, the authentication system can send the QR code or a locator(e.g., link, URL, etc.) of the QR code to the server 606 in response tothe server request. The server can forward the code or the locator ofthe code to a display device 604 for display to the user. In someinstances, the display device 604 may be an unauthenticated (e.g.,unregistered) device with the authentication system. In some instances,the display device 604 may be the same device as a user device 602. Insome instances, the display device may function as an interface forusers to interact with the online service provider to open an onlineaccount (e.g., web browser or web portal that user can access toregister or sign up an online account). The user may scan the codedisplayed on the display device using a user device 602, such as via animaging device included in or otherwise communicatively coupled to theuser device. The imaging device can be hardware and/or software. Theuser device can then send the scanned code or image data of the scannedcode to a code analyzer in the authentication system to decrypt thecode. In some embodiments, instead of the raw code image, the userdevice may process and/or analyze the code, such as decode the serveridentity and session ID, and transmit the decoded data to theauthentication system. Once the code analyzer confirms that thevalidation ID of the received code uniquely matches a specific requestby the server, the authentication system may notify to the user on theuser device and/or the display device that the code is authentic, andthat the online service provider is verified. In some instances, theauthentication system may notify the user by sending a message.Alternatively, if the code analyzer determines that the code does notcontain a valid validation ID or the validation ID has expired, theauthentication system may notify the user that the code is invalid, andthat the online service provider is foreign to the authenticationsystem. Alternatively or in addition, the authentication system may warnthe user of potential fraud in the process.

In some instances, along with the QR code or image data of the QR code,the identity of the user device (e.g., user device ID) and/or the user(e.g., user ID) may also be submitted to the authentication system.Subsequently, the authentication system may identify the user in theauthentication system and locate the user information data associatedwith the user. From the server request and the validation ID, forexample, the authentication system may also identify the online serviceprovider and locate the user information requirement data associatedwith the online service provider. The user information requirement datamay comprise one or more user information categories. From the onlineservice provider's user information requirement data, the authenticationsystem may identify the required user information categories andretrieve the selected categories of user information from the user'suser information data. The authentication system may provide the userinformation data to the online service provider either directly orthrough the user device. For example, the authentication system canprovide the user information to the user device and/or the displaydevice for display to the user. The user may add, edit, or remove one ormore user information fields before submitting the user information tothe online service provider (through the server 606). If theauthentication system lacks one or more categories of required userinformation (e.g., secondary email address, security question andcorresponding answer, etc.), the user may be prompted to provide the oneor more categories of required user information to the server and/or theauthentication system. Once the server confirms receipt of all requireduser information for opening an online account, either having receiveddirectly from the authentication system or from the user through a userdevice and/or a display device, the server may open an online accountfor the user.

In some embodiments, the online account can be opened via a networkbetween the user device 602 and the server 606 which bypasses thedisplay device. The communications between the user device andauthentication server, authentication server and service providerserver, and user device and service provider server can be secured usingvarious encryption techniques. Any combination of server certificates,secure sockets layer (SSL), secured protocol such as TLS (transportlayer security) and/or internet protocol (IP) addresses can be used tosecure the communications within the network.

An overview of the online account opening process is shown in FIG. 7.The process begins when a user requests to open an online account withan online service provider through a server 702 associated with theonline service provider. Upon the user request, the server requests aone-time code to a code generator 704 of the authentication system. Insome embodiments, the code is a QR code. Upon receiving the serverrequest, the code generator generates a one-time QR code encoding avalidation ID containing the identity of the online service providerand/or the server identity. The server receives the QR code or a locatorof the QR code, such as a link that can be used to retrieve the codestored in the authentication server, then displays the QR code to a useron a display device 706. The user scans the QR code with a user device708, which may or may not be the same device as the display device, andtransmits the code or processed data of the code to a QR code analyzer.The code analyzer may decode the validation ID from the code receivedfrom the user device and confirms the identity of the online serviceprovider 710. If the service provider is authenticated, theauthentication system locates the user information requirement dataassociated with the online service provider 712 and identifies therequired user information categories for the user to open an onlineaccount with the online service provider. At step 710, theauthentication system may further confirm the identity of the user suchas via a user id or a user device id transmitted with the QR code. Theauthentication system may retrieve user information of the user for theuser information requirement categories of the online service providerand provide the selected user information to the online service provider714.

For all examples and figures depicting the use of a QR code, anotherform of graphical authentication indicia may be used in place of the QRcode, such as another type of visual graphical barcode, images,pictures, or videos. The visual graphical barcode may be scanned by auser device which includes or is otherwise communicatively coupled to animaging device.

The visual graphical barcode can be any format, such as a bar code,text, a picture, a sequence thereof, or the like that can be capturedand/or displayed on a device. The visual graphical barcode may be atwo-dimensional barcode, such as PDF417, Aztec, MaxiCode, and QR code,etc. The visual graphical barcode may be a one-dimensional barcode, suchas Interleaved 2/5, Industrial 2/5, Code 39, Code 39 Extended, Codabar,Code 11, Code 128, Code 128 Extended, EAN/UCC 128, UPC-E, UPC-A, EAN-8,EAN-13, Code 93, Code 93 Extended, DataBar Omnidirectional (RSS-14),DataBar Truncated (RSS-14 Truncated), DataBar Limited (RSS Limited),DataBar Stacked, DataBar Expanded, and DataBar Expanded Stacked, etc.The visual graphical barcode can encode various types of information inany type of suitable format, such as binary, alphanumeric, ASCII, andother formats, and the code can be based on any standards. The visualgraphical barcode may have various storage capacities that can encode acertain amount of data, and variable physical size. In some embodiments,the visual graphical barcode may conform to known standards that can beread by standard barcode readers. In other embodiments, the visualgraphical barcode may be proprietary such that it can be read only by anauthenticated application provided by an authentication system runningon a user device. In some instances, only the authentication system orthe authenticated application can be capable of encrypting/decryptingthe visual graphical barcode.

The visual graphical barcode can be a one-dimensional barcode,two-dimensional barcode or three-dimensional barcode. The visualgraphical barcode can be, for example, one-dimensional barcode thatincludes linear patterns such as lines and spaces. The lines and spacesmay be black-and-white. The lines and spaces can comprise more than onecolor. The color may be visible to human eyes. The color of the barcodemay be distinguishable by special tools. For instance, the barcode mayinclude print carbon lines which are detectable using an infraredscanner. The visual graphical barcode can be a two-dimensional barcodeincluding various shapes. The visual graphical barcode may be static ordynamic. The visual graphical barcode may be changed or updated at acertain frequency. The frequency may vary widely in range, such as from100 Hz to 0.001 Hz.

In one aspect, additional security measures can be provided for theauthentication session. The additional security measures may beresistant to replay attacks. In some instances, nonce data may becollected and used as anti-replay features. The nonce data may begenerated when an imaging device is used to scan the visual graphicalbarcode.

In some instances, nonce data may be collected relating to a state of ascanned image of a visual graphical barcode or an imaging device duringthe first transaction. The nonce data may include one or more sets ofsingularity values (e.g., nonce factors) that may realistically onlyoccur once, and would not naturally be repeated. Thus, repetition of thenonce data may be cause for suspicion that a replay attack may beoccurring. The nonce data may relate to an internal state of the imagingdevice, the user device or component of the user device, or may includedata that may be collected relating to a scanned image that contains thevisual graphical barcode or the graphical authentication indicia. Thenonce data may include image capture information such as metadata,positional information, or any other information relating to the imagingdevice. The nonce data may also include information generated duringprocessing of the image for context analysis.

The nonce data can be generated at any phase during a transaction. Forexample, nonce data indicative of a state of a user device and/or anenvironment can be generated at the beginning of an authenticationsession, during scanning of a visual graphical barcode, and/or aftertransferring the barcode to the server. In another example, the noncedata may be indicative of a user behavior such as a touching activity ona touch-sensitive screen of the user device.

The nonce data can be generated during the scanning of the visualgraphical code using an imaging device. The nonce data may be generatedbased on various parameters of the image containing the visual graphicalcode. The parameters may be obtained during pre-processing operationssuch as auto-adjustment of the raw image by the imaging device, such asby a camera (e.g., balance correction, gamma correction, de-mosaicing,de-speckle, etc). The parameters may be obtained during image processingoperations in order to recognize a physical token and/or decode thetoken, such as image segmentation, edge detection, corner detection,pattern detection, measurement of image skew angle and rotation,measurement of pixel content, histograms, image scaling, smoothing,morphological filters, and etc. The nonce data can be obtained in thecontext of the whole image or a recognized region of interest. The noncedata may be generated based on a state of the imaging device, such asexposure settings, capture time, GPS location information, and cameramodel, etc.

FIG. 8 shows a schematic illustration of a user device 804 capturing avisual graphical barcode in accordance with an authentication session.The authentication session may be hosted by a server (such as the server201 of FIG. 2) on one or more interactive webpages, and accessed by oneor more users. In some instances, the components, and functions and/orbehaviors of the components, in FIG. 8 may correspond to the components,and the functions and/or behaviors of the components, in FIG. 1. In someinstances, a component of FIG. 8 can be the same component of FIG. 1.For example, the user device 104 in FIG. 1 may correspond to the userdevice 804 in FIG. 8. For example, the imaging device 103 in FIG. 1 maycorrespond to the imaging device 803 in FIG. 8. For example, the displaydevice 101 in FIG. 1 may correspond to the display device 801 in FIG. 8.For example, the authentication system 102 in FIG. 1 may correspond tothe authentication system 802 in FIG. 8. All functions, capabilities,and connectivity of the components in FIG. 1 may apply to the componentsin FIG. 8.

The user device 804 can be used to scan a visual graphical barcode orgraphical authentication indicia 805. The visual graphical barcode orgraphical authentication indicia may be displayed on a display device801. The user device 804 and the display device 801 may be separatedevices or the same device. In some instances, the graphicalauthentication indicia may be provided on a physical object or beprovided in the form of a physical object.

In some instances, a photo of the visual graphical code 805 may beacquired and stored on a memory unit of the user device 804 for furtherimage processing and decoding. Alternatively, the imaging device 803 mayscan the visual graphical code in real time without capturing a photo ofthe barcode. In some instances, the imaging device 803 may constantlyacquire images of the visual graphical code and store them in memory.Each of these images can be subsequently processed by the user deviceuntil the visual graphical code is correctly decoded. Once the visualgraphical code 805 has been decoded, the imaging device 803 may stopacquiring images of the visual graphical code.

In some instances, the user device 804 may comprise one or more sensors.The one or more sensors may be configured to collect data indicative ofa state of the user device, a state of the imaging device and/or noncedata generated during a process. The one or more sensors may include,but are not limited to, location sensors (e.g., global positioningsystem (GPS) sensors, mobile device transmitters enabling locationtriangulation), vision sensors (e.g., imaging devices capable ofdetecting visible, infrared, or ultraviolet light, such as cameras),proximity sensors (e.g., ultrasonic sensors, lidar, time-of-flightcameras), inertial sensors (e.g., accelerometers, gyroscopes, inertialmeasurement units (IMUs)), altitude sensors, pressure sensors (e.g.,barometers), audio sensors (e.g., microphones), time sensors (e.g.,clocks), temperature sensors, sensors capable of detecting memory usageand/or processor usage, or field sensors (e.g., magnetometers,electromagnetic sensors). Any suitable number and combination of sensorscan be used, such as one, two, three, four, five, or more sensors.Optionally, the data can be received from sensors of different types(e.g., two, three, four, five, or more types). Sensors of differenttypes may measure different types of signals or information (e.g.,position, orientation, velocity, acceleration, proximity, pressure,etc.) and/or utilize different types of measurement techniques to obtaindata. For instance, the sensors may include any suitable combination ofactive sensors (e.g., sensors that generate and measure energy fromtheir own source) and passive sensors (e.g., sensors that detectavailable energy).

Any number of sensors may be provided on-board the user device 804. Thesensors may include different types of sensors, or the same types ofsensors. The sensors and/or any other components described herein may beenclosed within a housing of the device, embedded in the housing of thedevice, or on an external portion of the housing of the device. Thehousing may or may not form a fluid-tight (e.g., water-tight orairtight) seal separating the interior of the housing and/or theexterior of the housing. Alternatively or in addition, the sensors maybe external to the housing of the device and communicatively coupled, bycable or wirelessly, to the user device.

In some instances, the user device 804 may comprise a touch-sensitivetouch screen 806. The touch-sensitive touch screen may provide an inputinterface and an output interface between the user device and a user.The touch screen may display visual output to the user. The visualoutput may include graphics, text, icons, video, and any combinationthereof (collectively termed “graphics”). In some instances, some or allof the visual output may correspond to user-interface objects thatinstruct a user to, for example, confirm an online account openingprocess by touching a graphical button on the touch-sensitive touchscreen. In some cases, a location of the touching may be recorded. Theposition of the touching on the touch screen (e.g., X, Y coordinates)may be used as nonce data.

In some instances, the visual graphical code 805 displayed on thedisplay device 801 can be any type of graphical code as describedpreviously herein. The visual graphical code may be referred to as avisual graphical barcode or graphical authentication indicia. In someinstances, the visual graphical code may be a one-time visual graphicalcode. The visual graphical code may expire or time out after a certainperiod of time or once it has been validated. Alternatively, the visualgraphical code may be presented to the user as a physical object. Thevisual graphical code may be on a physical element possessed by a user.The physical element may be a card (e.g., ID card, driver license,payment card, library card, login card, one time password (OTP) token,etc.), documents (e.g., passport, legal document, healthcare record,etc), and the like that are issued or provided by an entity or an onlineservice provider. In other instances, the visual graphical code can bedisplayed on a display device as graphics.

As mentioned previously, nonce data may be used to provide an additionallayer of security during an authentication session. Any description ofnonce data may apply to various device measurements, indices, orparameters that may be unlikely to repeat. Nonce data may include or bederived from one or more nonce factors. The one or more nonce factorsmay include various types of data collected about a state of the userdevice, a state of the imaging device and/or a state of the capturedimage data. The nonce factors may include an activity performed by theuser such as a touching on the touch screen. The nonce factors mayinclude data from various sensors of the user device. The nonce factorsmay include various types of data collected about a state of the userdevice. The nonce factors may each be taken at a single point in time,multiple points in time, or over a time interval. Each of the noncefactors may be from different points in time, or may be from points intime that coincide and/or overlap. Each of the nonce factors may includedata collected from different sensors or different types of sensors ofthe device. Alternatively, two or more of the nonce factors may becollected from the same sensor or same type of sensor. In someinstances, all of the nonce factors may be collected from the samesensor or same type of sensor.

A state of the user device may include environmental informationcollected by the user device during an authentication session. Theenvironmental information may include audio information collected by amicrophone of the device. The environmental information may includeinformation collected by a motion detector, an ultrasonic sensor, lidar,temperature sensor, pressure sensor, or any other type of sensor thatmay collect environmental information about the user device. Theenvironmental information may include detecting the touch or a handposition of a user holding the device, and collecting which portions ofthe user device has been touched or held by the user.

FIG. 9 illustrates an example of a user device collecting nonce data. Auser device 900 may be used to open an online account through anexternal device (not shown in FIG. 9), such as a display device 801. Auser may be prompted to scan a visual graphical barcode displayed on theexternal device using the user device. Once the user is verified, theuser may be permitted to open an online account through the externaldevice. The user device 900 can be the same user device 804 described inFIG. 8. The user device may comprise a touch-sensitive display screen907. In some instances, the user device may further comprise microphones903 for collecting audio data or any other sensor for collecting sensordata. The user device may be used to scan the visual graphical barcode,such as via an imaging device (e.g., camera). After a visual graphicalbarcode is scanned by the user device and verified by an authenticationsystem (e.g., authentication system 802 in FIG. 8), the user may beprompted to click on a graphical object 901 (e.g., button, icon, etc.)on the user touch-sensitive display screen to continue the process.Alternatively, other types of nonce data such as data related to a stateof the device can be used such that a user may not be required to clickon the graphical object in order to continue the authentication process.

The graphical object 901 can be a visual representation of any graphicalshape. It should be noted that various characteristics of graphicalelements can be used as the visual representation such as color, shape,and image contents. A user may be prompted to click or touch thegraphical object to verify that the user wants to proceed with openingan online account. For instance, a user may be provided a message (e.g.,“Please click Accept to proceed.”) to verify whether the user intends toopen an online account by clicking or touching the graphical object(e.g., button shape graphical object). In some instances, the locationor X and Y coordinates 905 of the location where the user touches thegraphical object may be recorded and used as a nonce factor. Thelocation where the user touches the screen is unlikely to be exactlyidentical every time. In some instances, an X and Y coordinates may bewith respect to the touch-sensitive display screen 907. The X and Ycoordinates may be with respect to a graphical element displayed on thescreen such as the graphical object.

The nonce data may be transmitted to the authentication system by theuser device 900. For example, the user device may transmit nonce datasimultaneously with the scanned QR code data to the authenticationsystem. Alternatively, the user device may transmit nonce dataindependently (e.g., at a different point in time) of the scanned QRcode but along with a session ID to associate the nonce data with aparticular authentication session. The nonce data may be stored ashistoric data in one or more databases (such as the database 512 in FIG.5) accessible to the authentication system. The nonce data may be storedper authentication session, and retrieved and compared to new nonce datafor each new authentication session. Alternatively or in addition, thenonce data may be stored per user device, and retrieved and compared tonew nonce data for each new authentication session by the same userdevice. Alternatively or in addition, the nonce data may be stored peruser, and retrieved and compared to new nonce data for each newauthentication session by the same user. Alternatively or in addition,the nonce data may be stored per online service provider, and retrievedand compared to new nonce data for each new authentication sessioninvolving the same online service provider. Alternatively or inaddition, the nonce data may be stored per service provider server, andretrieved and compared to new nonce data for each new authenticationsession by the same service provider server. The authentication systemmay complete the authentication session after verifying that the newnonce data is not a copy of historic nonce data, indicating a replayattack. The authentication system may proceed to provide userinformation to an online service provider only after verifying the noncedata.

In some instances, an authentication code may be provided to the user inaddition to a visual graphical code, separate from the validation codethat may be encoded in the visual graphical code. For example, if a useris tricked into scanning fraudulent or counterfeited visual graphicalcodes thereby unintentionally providing user information (e.g., userdevice ID, etc.) to a fraudulent source, it would be beneficial for theuser to first verify the authenticity of the visual graphical code. Theauthentication code may be used to verify the authenticity of the visualgraphical code. The authentication code may be, for example, an audiocode that is played on an external device (such as the display device801 in FIG. 8). The audio code may be generated by an authenticationserver (such as the authentication server 508 in FIG. 5), such as instep 704 of the process outlined in FIG. 7. The audio code may beuniquely associated with a visual graphical code. The audio code may beuniquely associated with a user device (e.g., user device ID) or useraccount (e.g., user ID). The external device that can play the audiocode may be the same device that displays the visual graphical code.Alternatively, the external device may be communicatively coupled to thedevice that displays the visual graphical code. The external device maycomprise a sound emitter configured to emit audio codes. The audio codesmay be played simultaneously when a visual graphical code is displayedto a user for scanning. The audio codes may be collected by themicrophones 903 of the user device 900 and the visual graphical code maybe scanned by the imaging device of the user device. The user device maythen transmit both the audio code and the visual graphical code to theauthentication server for authentication. The authentication server mayverify both the audio code and the visual graphical code. If the codesdo not match, either with each other or with a stored copy of therespective code in the authentication system that generated the code,the lack of match may be indicative of a counterfeited visual graphicalcode.

The authentication code (e.g., audio code) and the nonce data can beused in combination or separately. In an example, an audio code may beverified first to identify the authenticity of the visual graphicalcode, and the nonce data may be verified next to detect any replayattack. The audio code and the nonce data may be used in any order orsimultaneously. Using the audio code and/or the nonce data may providean additional layer of security to the authentication session andbeneficially protect against phishing or replay attacks.

In another aspect of the disclosure, a system or method for identityproofing and authenticating users is provided. The identity proofing andauthenticating method may be compliant with, for example, the NationalInstitute of Standards Technology (NIST) special publication800-063-2(electronic authentication guideline), which is herebyincorporated by reference in its entirety. The method may be implementedusing a system comprising computing devices that may communicate witheach other via a network, and by way of one or more trust and securityagreements between entities in the system that dictate how the entitiesare to interact with each other and/or that indicate which entities areliable for which occurrences in connection with interactions. The methodmay follow the guideline of NIST level of assurance (LOA) 1-4 and mayfurther comprise features expanding upon it. For example, the method asdescribed may provide three levels of identity proofing, three levels ofauthentication and/or an anti-replay feature.

The National Institute of Standards and Technology (NIST), hasestablished various standards defining levels of trust for trustedidentities. NIST refers to these standards as Level of Assurance or LOA.Several of these standards involve in-person identity proofing, lookupprocesses associated with government-issued identity cards, and severalother forms of processes to ensure that the requesting party is provento be who they claim to be before they can be issued a trusted identity.

As noted above, NIST refers to each standard level of trust as a Levelof Assurance (LOA). NIST has established various numbers associated withthe LOA depending on how rigorous a party desires the authenticationprocess to be. These range from LOA 1, the weakest level of trustedidentity, to LOA 4, the highest level of trust that a person possessingand using a trusted identity is authenticated as being the person towhom the trusted identity was issued. At LOA1 although there is noidentity proofing requirement at this level, the authenticationmechanism provides some assurance that the same user who participated inprevious transactions is accessing the protected transaction or data. Itallows a wide range of available authentication technologies to beemployed and permits the use of any of the token methods of LOAs 2, 3,or 4. Authentication of LOA 1 may be implemented by verification a useridentity via a federated user account such as email address. Ananti-replay feature may be included at LOA 1. For instance, when theuser is asked to provide email address, nonce data may be collected bythe user device when the information is sent out.

LOA 2 provides a single factor remote network authentication. At LOA 2,identity proofing requirements are introduced, requiring presentation ofidentifying materials or information. Identity proofing may be performedin various ways with various security levels. For instance, identityproofing may be performed at levels ‘good’, ‘better’ and ‘best’. In anexample, at level of ‘good’, identity proofing may use verified emailaddress, by asking the user to provide data sent to the email account.This may not prove the identity per se, rather, establishes access tothe internet handle that can be used later on. In an example, at levelof ‘better, identity proofing may use a remote scan of a governmentissued ID, such as driver license PDF 417 or Passport MRZ (machinereadable zone). For additional confidence, a third party identityverification can be used. In an example, at level of ‘best, identityproofing may conduct an in-person identity proofing, using a PassportNFC chip, to validate the document with high certainty. Detailsregarding the various confidence levels of identity proofing arediscussed later herein.

LOA 3 provides multi-factor remote network authentication. At least twoauthentication factors are required. At this level, identity proofingprocedures require verification of identifying materials andinformation. The identity proofing may be conducted remotely or online.LOA 3 authentication is based on proof of possession of the allowedtypes of tokens through a cryptographic protocol. The tokens may bedifferent credentials used to authenticate a user. The credentials mayor may not contain an identity of the user. Optionally the credentialsmay or may not contain attributes to the identity of the user. Forexample, the credential may contain verified name of the real user orpseudonyms. The credentials can be any form. The credentials may beelectronic such as digital document that can be stored as data. Thecredentials can be secret information that the user knows such as username and password. The same credentials may be used repeatedly fordifferent authentication processes. The credentials may be generatedlater as needed such as QR code. The credentials may be a visualgraphical barcode such as driver license PDF 417 as described elsewhereherein. In some cases, at LOA 3, the credentials may be mainly softwarebased. Anti-replay features may be included at LOA 3 to eliminate riskof anti-replay attack.

LOA 4 authentication is based on proof of possession of a key through acryptographic protocol. At this level, in-person identity proofing isrequired. LOA 4 is similar to LOA 3 except that only “hard”cryptographic tokens are allowed. The tokens may be physical object suchas a physical token that can be possessed and controlled by a user(e.g., paper credential, card, finger print reader, card reader, etc).The token may be, for example a magnetic card possessed by the user. Useof the magnetic signature of a magnetic stripe accompanied by ananti-replay feature may provide a 100% guarantee of the validity of theauthenticator. Anti-replay features can be in the authentication processat one or more of the LOAs. Anti-replay features may be included at LOA4 to eliminate risk of anti-replay attack. For instance, nonce data maybe collected at the user device when a magnetic card swipe is performed.

The identity proofing and authentication method further providesanti-replay features to add additional level of assurance. Variousmethods may be used to provide anti-replay protection. For example,nonce data relating to a device used to provide user credentials may becaptured and used as anti-replay protection. The nonce data can berelated to various factors, such as the device used for authenticationor credential delivery, and the credential itself, etc. The nonce datamay change with respect to time, geo location, motion, device status andany environmental factors. Ideally the nonce data should not be repeatedthat is a singularity. Having exactly the same nonce data may indicate areplay attack. The anti-replay feature can be generated at any time. Forexample, the anti-replay protection may be generated at the time acredential is provided by the user before transferring it to anauthentication system.

FIG. 10 schematically illustrates a system implementing an identityproofing and authentication method. The identity authentication servicesmay be used to protect various activities requiring identityauthentication. The activities may or may not include the exchange ofmoney, goods, services, and/or information. The method or system may beused to grant access to sensitive and valuable assets. For example,access to high-value wire transfers, health records, privilegedaccounts, institutional banking, brokerage accounts, access to criticalinfrastructure (e.g., energy infrastructure, nuclear power plants) andremote or online access to mission-critical applications may beprotected by the identity authentication method.

A user 1003 may perform an authentication for a user activity. In oneexample, the user may perform a transaction of exchanging money, goods,and/or services with a third-party entity or a relying party 1007. Inanother example, the user may purchase an item online from ane-commerce. In yet another example, the user may transfer money to abroker system. In another example, the user may login to apre-registered user account on a social networking platform. In anotherexample, the user may try to open an online account with an onlineservice provider. In yet another example, the user may request access toa critical infrastructure or sensitive information. The user may performthe activity on a website or in an application associated with thethird-party entity or the relying party.

The user may or may not log into a registered user account with thethird-party entity (e.g., a public service, an online voting system, asocial networking service, etc.) to perform the activity. In some cases,the user may try to open an online account with the third-party entity.The user may or may not register to the identity authentication service1001 prior to the activity/transaction.

An identity of a user 1003 may be proofed. The identity proofing may beconducted at different identity assurance levels. In some cases,different identity documents or materials may be used to uniquelyidentify a user. The identity-proofing assurance level may be affectedby different security levels of the identity documents and also affectedby how the identity proofing document is presented and examined.

The documents may be physical documents such as a card, a paperdocument, or other form of credentials issued by an authority entitysuch as government, DMV, federal agency, etc. In some embodiments, theidentity documents may be a person's civil credential such as socialsecurity card, passport, driver license, e-passport, birth certificates,employee identity cards, etc. Additionally, the identity documents usedto establish identity of a user may also include records in a database,electronic identity information, etc. For example, Federal Tax ID may beused to establish identity of a company.

Different identity documents or materials may have different securitylevels. The security level may refer to various security features usedby the identity document to prevent counterfeit. The identity documentscan be authenticated in a variety of ways: signal, seal, special papersand inks, high quality engraving, holograms, cryptographic techniquesetc that make the identity documents recognizable and difficult to copyor forge. A driver's license that is printed on a plastic card and hassecurity features that are both overt and covert (e.g., ink visible onlyunder black light, magnetic stripe) be a level higher than socialsecurity card. A passport that is printed on specialty paper and isbound in a booklet may have security features that are both overt andcovert (e.g., ink visible only under black light, magnetic stripe). Thespecial material and government printing may make a passport a levelmore secure than a driver's license. An E-passport that has a NFC/RFIDchip embedded in it containing a person's identity information and ismade in layers, which include government printing of the booklet andstate department issue of the chip and its cryptographic seal, may makethe E-passport a high level of security.

Different ways an identity document is presented or examined may havedifferent trust or confidence level. An identity document may bepresented in different ways. The different ways may be in-personproofing, remote proofing or online proofing, etc. In some cases, thedifferent ways may be categorized into multiple levels. For example,identity proofing may be divided into levels including Know, Show,Present and Prove. Different levels of identity proofing may beassociated with different difficulty levels to falsify or differentlevels of in-person participation of the user. Taking a U.S. passportwith NFC chip as example, at a level of ‘Know’, a user may prove that heis who he claims to be by showing he knows information of the passportsuch as the passport number. The person may present his knowledge of thepassport by various means such as entering the information by typing iton a website via a user device, say the information over the phone or inperson. The information provided by the person may be sufficient toestablish a unique identity of the user as stated by the identityproofing document. At the level of ‘Show’, the user may show thepassport remotely via any suitable means. For example, the user may scanthe passport using a camera on a mobile or any PC device then transferthe electronic copy of the passport (e.g., captured image) includingrequired information such as MRZ (machine readable zone) information.The transfer method may involve any suitable device such as mobiledevice and desktop via any suitable communication means such as on-line.The transfer method may or may not use cryptographic techniques. Theuser may present information that may be attainable from the identitydocument. Optimally, the user may present information that may only beknown if the user has the identity document or one had the identitydocument in the user's possession. At the level of ‘Present’, the usermay present the passport in-person to an authorized agent or authorizedentity. The authorized agent or entity may have certain expertise suchas the ability to recognize and verify a picture ID card and/or thecapability of use a specialized infrastructure to extract the identityinformation. For example, an optical device may be provided to theauthorized agent or entity for inspecting the passport by reading animage of the MRZ in order to extract the identity information of theuser. At the level of ‘Prove’, the user may present the passportin-person to an authorized agent or entity. The authorized agent orentity may be equipped with specialized infrastructure or technology toprove the authentication of the identity document. For example, theauthorized agent or entity may be equipped with specialized devices(e.g., MRZ reader, optical reader or scanner, magnetic reader) toinspect one or more security features of the physical identity documentas described previously to identity whether the identity document is acounterfeit. In some cases, during the different presentation processes(e.g., Know, Show, Present and Prove), one or more factors associatedwith inspecting or authenticating the identity document may beautomatically recorded. For example, when a user presents a passportin-person to an authorized agent, one or more factors (e.g., ‘Prove’level, presentation location, relationship between the user and theagent, etc) related to the identity document and presentation processesmay be automatically recorded in a database accessible by the system. Insome cases, a device may be used to authenticate or inspect an identitydocument and the device may transmit wired or wireless communication theidentity information captured or identified by the device to one or moreprocessors for analysis. The device may be an optical device, a scanner,a magnetic stripe reader, etc. Data transmission can be realized by anyfeasible means such as wired or wireless communication.

In some embodiments, the first level of identity proofing assurance maynot require an identity proofing document. A user may be asked toprovide a federated account such as an email account to establish anaccess to services provided by the identity authentication servicesystem 1001. The federated account may be used as a single authenticatedservice account that can be re-used across multiple online services. Theuser account may be used to establish a connection of the user tovarious relying parties in a federated manner. Various other accountscan be employed such as social network account, email address and thelike. The federated account may be provided as a user identifier foruniquely identifying a user by a relying party meanwhile providing acommunication or verification channel between the user and the relyingparty/identity authentication service system. In some embodiments, thesecond level of identity proofing may require one or more identityproofing documents or third party record, such as a driver license or apassport or a healthcare record to be inspected remotely, such as aremote scan. In some embodiments, the third level of identity proofingmay require an in-person identity proofing to inspect one or moreidentity proofing documents with the high security level, such as apassport with NFC chip. In some cases, at all levels, a federated useraccount such as the email account may be required.

In some embodiments, the users 1003 may provide their identity or anemail address to the identity authentication service 1001 when theyregister to the identity authentication service system. The identityauthentication service system may perform identity proofing of the userby requiring identity proofing document via certain presentation means.Once the identity of the user is proved, the identity authenticationservice 1001 may or may not issue one or more credentials to the users.The credentials can be used for later authentications. In some cases,once the identity of the user is proved, an access to the authenticationservices provided by the identity authentication service system may beestablished. For instance, the user may be allowed to use barcodescanning functions provided by a mobile application running on theidentity authentication server. Different credentials may be used toauthenticate a user. The credentials may or may not contain an identityof the user. Optionally the credentials may or may not containattributes to the identity of the user. For example, the credential maycontain verified name of the real user or pseudonyms. The credentialscan be any form. The credentials may be physical object such as aphysical token that can be possessed and controlled by a user (e.g.,paper credential, card, finger print reader, card reader, etc). Thecredentials may be electronic such as digital document that can bestored as data. The credentials can be secret information that the userknows such as user name and password. The same credentials may be usedrepeatedly for different authentication processes. Different credentialsmay be used for different authentication processes. The credentials maybe generated later as needed such as a QR code.

As mentioned previously, the identity authentication service 1001 mayprovide authentication services at different levels of assurance. Insome embodiments, the first level may be a two-factor authentication.The first level of authentication may require something you know (e.g.,PIN) and/or something you are (e.g. biometrics). For instance, a usermay be asked to input a PIN or provide a fingerprint via a user device.In some cases, anti-replay features may be provided along with thecredentials. In some embodiments, the second level may include anadditional factor relative to the first level. In some cases, theadditional factor may be scanning of a visual barcode or an identityproofing document (e.g., PDF 417 on a driver license). This additionalfactor may be something you have. In some embodiments, the third levelmay include use of a physical token such as a magnetic card to provideadditional security relative to the second level. In some embodiments,some or all of the authentications are performed via a mobileapplication running on the user device 1005. In some cases, the userdevice 1005 may be pre-registered with the identity authenticationservice system and have a unique device ID stored in a database that isaccessible by the identity authentication service system.

The one or more users may try to gain access to one or morerelying-party entities 1007. A relying party (RP), e.g., the web sitestoring resources being accessed by the second site, sets a policy thatallows a requester (e.g., a user, another RP, the third party web siteaccessing the secured resources) access to a resource controlled by theRP based on a set of authenticated user attributes (e.g., username,address, age, and the like). The resource to be accessed may be, forinstance, protected data, a particular computing device, an account, atransaction, or a computing function. The relying party may include, butare not limited to, a merchant's system, a broker's system, a creditcard company, a social network platform, a government department, acritical infrastructure, and/or other entities that may require userauthentication. The relying party may be configured to offer variousservices to the user which may or may not include exchange of moneyand/or goods. The services may include any situation whereauthentication may be required using one or more credentials asdiscussed elsewhere herein. The services may be performed completelyonline (e.g., online shopping, online social networking, onlineregistration and/or fee payments). The services may be performedcompletely in physical locations (e.g., shopping at a supermarket,backing services at a bank, registration at the city hall, etc.). Theservices may also include partially online activities in combinationwith partially physical activities. For a user to access theRP-protected resource, an identity authentication service 1001 that isacceptable to the relying party will authenticate the user identityusing one or more credentials, and the identity authentication service1001 will provide the verified user identity or approved user identifierto the relying party.

The relying parties 1007 may be implemented on one or more standalonedata processing apparatuses or a distributed network of computers. Theone or more relying parties may comprise one or more RP servers. In somecases, one or more RP servers may be implemented in software, hardwareor a combination of both. The RP servers may be, for example, bankingwebsite, government service website, social networking websites,automated banking machines, point of sale machines, virtual privatenetwork systems, healthcare system, or other enterprise servers.

In some cases, the one or more users may access services provided by theone or more relying-parties via one or more accessing devices 1009. Auser may access information or services provided by the RP via a clientinterface, such as a browser executing on the accessing device or abrowser executing on the user device. In some cases, the user may try toregister or open a new account with the relying-party. The accessingdevice 1009 can be a monitor, a computer (e.g., laptop computer, desktopcomputer), a mobile device (e.g., smartphone, tablet, pager, personaldigital assistant (PDA)), or a vending machine. In some instances, theaccessing device may comprise one or more processors natively embeddedin the accessing device. The accessing device may optionally beportable. The accessing device may be handheld. In some embodiments, theaccessing device can be the same display device as described in FIG. 1.

The identity authentication service 1001 may include authorized agentwho is capable to authenticate identity proofing document in-person orremotely. The identity authentication service may also include or haveaccess to one or more databases for storing various information obtainedduring user registration process and features engaged in anauthentication processes. The various information may include but notlimited to, user identity information, federated account, identityproofing document information, authentication or presentation methods,user provided information associated with their account (e.g., challengequestions, username, password), information regarding credentials issuedto the user such as pre-registered card information (e.g., encoded data,magnetic fingerprint data, and/or swipe characteristics) of one or morecards of the user associated with a card reader, pre-registered accountinformation of the user associated with the card reader, pre-registereddevice information of the user device(s) which may have interactionswith the card reader, pre-registered device identifier of the cardreader, historic authentication reads data using the card reader,registration data registered using the card reader, and various otherfactors collected during the identity proofing process (e.g., location,time, public notary) and various features of the credentials. Thedatabases may also store information regarding various features of theauthentication processes.

The identity authentication service 1001 may be configured to performvarious authentications as required by various activities as discussedelsewhere herein. The various authentications may include verifying usercredentials with or without anti-replay features. The variousfunctionalities of the identity authentication service may befacilitated by use of one or more processors. The identityauthentication service may be facilitated by and/or have access to oneor more databases. The identity authentication service may beimplemented on one or more standalone data processing apparatuses.Alternatively, the identity authentication service may be implemented onone or more processing apparatuses and/or databases offered by adistributed network of computers (e.g., peer-to-peer or cloud-computingbased infrastructure). One or more functionalities of the identityauthentication service may be part of a server or accessed by a server.

The identity authentication service may be in communication with one ormore user devices and/or one or more user credentials 1005. Theauthentication service may be in communication with various user devicesand/or user credentials with aid of a communication unit (e.g., an I/Ointerface). The identity authentication service may be in communicationwith various external server systems (e.g., merchant's system, broker'ssystem, credit card companies, social network platforms, and/or otherentities). The identity authentication service may be in communicationwith various external server systems with aid of one or more I/Ointerfaces. The I/O interface to the user devices and/or the usercredentials may facilitate the processing of input and output associatedwith the user devices and/or the card readers respectively. For example,the I/O interface may facilitate the processing of a user inputassociated with a request for secure authentication. The I/O interfaceto external server systems may facilitate communications with one ormore third-party entities (e.g., merchant's system, broker's system,credit card companies, social network platforms, and/or otherthird-party entities).

The user devices, accessing devices, RP servers or identityauthentication servers may communication with each other via one or morecommunication networks. The communication network(s) may include localarea networks (LAN) or wide area networks (WAN), such as the Internet.The communication network(s) may comprise telecommunication network(s)including transmitters, receivers, and various communication channels(e.g., routers) for routing messages in-between. The communicationnetwork(s) may be implemented using any known network protocol,including various wired or wireless protocols, such as Ethernet,Universal Serial Bus (USB), FIREWIRE, Global System for MobileCommunications (GSM), Enhanced Data GSM Environment (EDGE), codedivision multiple access (CDMA), time division multiple access (TDMA),Bluetooth, Wi-Fi, voice over Internet Protocol (VoIP), Wi-MAX, or anyother suitable communication protocols.

In some instances, one or more user devices 1005 may be in communicationwith the identity authentication service with respective credentials. Insome instances, a user device may be a user credential. The user devicemay be used to scan a visual barcode displayed on the accessing device1009 for authenticating the user. The user device may be a computingdevice that is capable of executing software or applications provided byone or more identity authentication service systems. In someembodiments, the software and/or applications may allow the user to scana visual graphical barcode such as a QR code displayed on anotherdevice, and transmit authentication data between the user device andidentity authentication service system during an authentication session.The software and/or application may have been registered with theidentity authentication service system by the user. Optionally, thesoftware and/or application need not be registered with the identityauthentication service system, and only the user device may beregistered with the authentication system. Thus the device may have adevice ID stored in a memory accessible by the identity authenticationsystem. In some embodiments, the software and/or application may beconfigured to control an external device such as a card reader tocollect authentication data (e.g., swipe characteristics data, magneticfingerprint data, positional data, etc), and encrypt the data beforesending them to the identity authentication server during anauthentication session. In some embodiments, a visual graphical barcodebased authentication method is provided.

FIG. 11 illustrates an exemplary method for authenticating a user with arelying party. The method may provide authentication of a user withmultiple relying parties. The relying party may allow authenticated userto access resources, for instance, protected data, a particularcomputing device, an account, a transaction, or a computing function.The relying party may authenticate the user for various purposes, suchas for accessing a pre-existing user account or creating a new account.The relying party may employ one or more relying party servers 1105 anda user may seek to access services provided by the relying party via anaccessing device 1101 or the user device 1103. The user may beauthenticated by an identity authentication server 1107 via the userdevice 1103. The method may employ use of a visual graphical code. Asillustrated in FIG. 11, the visual graphical code 1109 displayed on adevice can be any type of graphical code as described previously herein.The visual graphical code may be referred to as visual graphical barcodeor graphical authentication indicia. In some instances, the visualgraphical code may be a one-time visual graphical code. The visualgraphical code may expire or time out after a certain period of time oronce they have been validated. The visual graphical code may be abarcode as described elsewhere here. In some cases, the visual graphicalcode may be a QR code as described in FIG. 1. Alternatively, the visualgraphical code may be presented to user as a physical object. The visualgraphical code may be on a physical element possessed by a user. Thephysical element may be a card (ID card, driver license, payment card,library card, login card, etc), documents (passport, legal document,healthcare record, etc), and the like that are issued or provided by anentity or service provider. In other instances, visual graphical codecan be displayed on a display device. In some embodiments, the displaydevice may be the accessing device provides user access to an account orto complete a transaction. Alternatively, the display device may not bethe accessing device. The display device may be a computer (e.g., laptopcomputer, desktop computer), a mobile device (e.g., smartphone, tablet,pager, personal digital assistant (PDA)), a vending machine or the likerequiring authentication or verification of the user to conduct asession or transaction utilizing the display device to complete thetransaction running on a server (i.e. service provider). The displaydevice may optionally be portable. The display device may be handheld. Auser device 1103 may be used to scan the visual graphical barcode forauthentication process. The user device can be the same user device 104as described in FIG. 1.

In some embodiments, a user may desire to access content or servicesprovided by a relying party (RP) server 1105 via an accessing device1101. For example, the user may try to access services using a browserexecuting on the accessing device. In another example, the user may tryto access services using a browser executing on the user device. Thebrowser may generate and transmit the request to the RP server foraccessing to resource or for authentication 1111. In some cases, theuser may not be required to input a user credential (PIN) or useridentifier (username) in order for the browser to send the request. Insome cases, a request for authentication may be generated in response toa user input indicating a login action or authentication action. Forinstance, a user may click on a login button indicating the loginaction. Alternatively, the user may need to input a user credential oruser identifier in order to send the request. Next, the RP server maygenerate a request for a visual graphical barcode (e.g. QR code) 1113and send the request for barcode to the accessing device 1115. In someembodiments, the RP server may generate the request for barcode usingApplication Programming Interface (API) or software development kit(SDK) provided by the identity authentication server 1107. Optionally,the user may be prompted on the accessing device about using the visualgraphical barcode. The browser running on the accessing device maygenerate and transmit a request for the associated authentication orlogin session to the identity authentication server 1117.

In response to the request, the identity authentication server maygenerate a visual graphical barcode along with an identifier uniquelyassociated with the barcode 1119. The visual graphical barcode may be aone-time barcode. In some embodiments, the identifier may be encoded inthe barcode to associate with the service session with the barcode. Theone-time barcode may be encoded with information such as the RP serverID, service provider identity or session ID as described elsewhereherein. Next, the one-time visual graphical barcode is sent to theaccessing device 1121. In some embodiments, the one-time barcode may berefreshed at certain time interval. For instance, the one-time barcodemay be refreshed every 10 s, 20 s, 30 s, 40 s, 60 s, 120 s, 5 minutes,10 minutes, and the like. In this case, the one-time barcode may beregenerated with refreshed information such as a new session ID ortimestamp while pertaining to the same. The one-time barcode may berefreshed when it is not scanned. This may be beneficial to avoid QRcode hijacking and various other attacks.

The visual graphical barcode is displayed on a display of the accessingdevice 1123. The display may be operably coupled to the accessingdevice. The display may be comprised by the accessing device. The usermay scan the visual graphical code using the user device 1125. In somecases, nonce data may be collected during scanning. The captured visualgraphical code may be decoded and processed by the application orsoftware that is provided by the identity authentication server 1107 andrunning on the user device. In some instances, the image data of thevisual graphical code may be directly sent to the identityauthentication server along with the device ID. In other instances, theapplication or software may process the captured code (e.g. decode thecode or decrypt the decoded data) and send the decoded information suchas the identifier along with the device ID to the identityauthentication server 1127. In some embodiments, in addition to theidentifier and the device ID, nonce data may also be included to detectanti-replay attack.

The identity authentication server may use the device ID to identify anassociated user 1129. In some cases, a user ID may be a user identifiersuch as a user name or user account that is used to register the userwith the identity authentication server. The user ID may or may notcontain private information about the user. In some cases, the user IDmay be a user identifier used only by the identity authenticationserver. The user ID may be transmitted to the accessing device 1131 toconfirm continuing the process for the associated user ID. A user mayconfirm request for accessing services or authentication for the user IDvia the accessing device and a request for accessing services provide bythe RP server user the user ID is transmitted to the RP server 1133. TheRP server may then send a request for verifying the user ID to theidentity authentication server 1135.

Next, the identity authentication server sends a request to theassociated user device for approval of verifying the user identity 1137.For instance, the user may be prompted on the user device indicatingverification or authentication is requested by the relying party orgranting permission to proceed with the service provided by the relyingparty. The request may be sent via the federated account such as theemail address. The federated account may be used as a singleauthenticated service account that can be re-used across multiple onlineservices. Various other accounts can be employed such as social networkaccount, email address and the like. The federated account may be usedto establish a connection of the user to various relying parties in afederated manner also provide an additional authentication channelbetween the user and the identity authentication server. In some cases,the request may be sent via the application running on the user device.This approval step may add additional security to the authenticationprocess. It may be beneficial of being able to quickly detect andeliminate the risk of QR code hijacking and various other attacks. Insome cases, the user can choose not to approve the request, forinstance, when the user does not recognize the relying party or theservice that requests authentication. It may be indicative of afraudulent event. In this case, the identity authentication server maynot provide any user related information to the relying party.

An approval for authenticating the user identity may be transmitted tothe identity authentication server when the user recognizes the relyingparty or the service 1139. Accordingly, the identity authenticationserver sends a federated account such as email address used at least bythe RP server for the RP server to identify the user 1141. The RP servermay determine authorization to the services or information as requestedby the user associated with the federated account 1143 and grant accessto the user on the accessing device 1145. In some cases, the RP servermay not recognize the federated account so the RP server may determineto create a new account for the user. In this case, the identityauthentication server may further provide user information retrievedfrom a user information requirement data to the RP server. The processfor the identity authentication server to provide user information foropening a new account with the RP server may include: identifying therequired user information categories from a user information requirementdata for the RP service provider, the identity proofing andauthentication system may, next, retrieve user information for theselected categories and provide the selected user information to the RPservice provider. This process may be the same as described with respectto FIG. 4. In some cases, instead of or in addition to the federatedaccount, information related to the user identity may be provided by theidentity authentication server to the RP server. The identityauthentication server may determine the type of information related toan authenticated user to be provided to the RP server. For example, fordifferent RP servers or different services, different type ofinformation may be provided. The information provided to a bankingserver may be different from the information provided to a healthcareinsurance server. In some cases, once a user is authenticated, only afederated account or user identifier that is recognizable by theassociated RP server may be provided which may minimize the risk ofexposing user information to a malicious party. The identityauthentication server may not need to have access to the user relatedinformation or services stored with the RP server. For example, when theRP server is a banking server, financial account of the user may not beaccessible by the identity authentication server. In some cases, thefederated account may be the only information shared between the RPserver and the identity authentication server. In some cases, additionaluser related information such as user name, device ID, address and thelike may be shared between the RP server and the identity authenticationserver.

It should be noted that the method should not be limited to the processas described above. One or more steps may be skipped or the order of thesteps may vary according to different applications. For example, thesteps 1137, 1139 for user approval of the authentication may be optionalsuch that a user may be automatically approved or authenticated byscanning a visual graphical barcode without providing additional userinput.

Anti-replay protection may be included in one or more steps during theauthentication process. Anti-replay feature may be used, for instance,when the user sends approval from the user device to the identityauthentication server or sends the device ID and identifier to theidentity authentication server. For example, nonce data relating to theuser device used to provide user credentials may be captured and used asanti-replay protection. The nonce data can be related to variousfactors, such as the device used for authentication or credentialdelivery, and the credential itself, etc. The nonce data may change withrespect to time, geo location, motion, device status and anyenvironmental factors. The anti-replay feature can be generated at anytime. For example, the anti-replay protection may be generated at thetime a barcode is scanned before transferring it to an authenticationsystem. The anti-replay protection may be generated at the time anapproval request is provided by the user. For instance a location of theuser touching a screen of the user device for approval of verificationcan be used as nonce data. The anti-replay protection may includeanti-replay features as described elsewhere herein.

In some embodiments, an authentication method without using a visualgraphical barcode may be provided. With respect to FIG. 12, the methodis illustrated in accordance with embodiments of the invention. Similarto the authentication process as described above, a user may desire toaccess content or services provided by a relying party (RP) server 1205via an accessing device 1201. For example, the user may try to accessservices using a browser executing on the accessing device. In anotherexample, the user may try to access services using a browser executingon the user device. The browser may generate and transmit the request tothe RP server for accessing to resource or for authentication 1211. Insome cases, the user may not be required to input a user credential(PIN) or user identifier (username) in order for the browser to send therequest. In some cases, a request for authentication may be generated inresponse to a user input indicating a login action. For instance, a usermay input a federated account such as email address to indicate arequest to login to the account. The RP server 1205 may look up thefederated account in a database accessible to the RP server 1213 thensend a request to the identity authentication server 1207 for averification of the federated account such as the email address 1215.The identity authentication server may send a request to a user device1203 associated with the federated account 1217 for approval ofverifying the user identity. The request may be sent via the federatedaccount such as the email address. The request may be sent via theapplication running on the user device. If the user approves to proceedwith verification, an approval may be transmitted form the user deviceto the identity authentication server 1219. Upon receiving the approval,the identity authentication server may send the verification resultassociated with the federated account to the PR server 1221. Next, theRP server may grant access to the resource or services to the user onthe accessing device 1201. In some cases, the RP server may notrecognize the federated account so the RP server may determine to createa new account for the user. In this case, the identity authenticationserver may further provide user information retrieved from a userinformation requirement data to the RP server. The process for theidentity authentication server to provide user information for opening anew account with the RP server may include: identifying the requireduser information categories from a user information requirement data forthe RP service provider, the identity proofing and authentication systemmay, next, retrieve user information for the selected categories andprovide the selected user information to the RP service provider. Thisprocess may be the same as described with respect to FIG. 4. It shouldbe noted that the user device may be pre-registered with the identityauthentication system as described elsewhere herein, such that anassociation of the device ID and the federated account may be pre-storedin a database accessible by the identity authentication server.

As described previously, the relying parties may be implemented on oneor more standalone data processing apparatuses or a distributed networkof computers. The one or more relying parties may comprise one or moreRP servers. In some cases, one or more RP servers may be implemented insoftware, hardware or a combination of both. The RP servers may be, forexample, banking website, government service website, social networkingwebsites, automated banking machines, point of sale machines, virtualprivate network systems, healthcare system, or other enterprise servers.In the example as illustrated in FIG. 13, the RP service provider is atransaction server 1307 and the device 1309 used for performingtransactions with a user 1303 may be an automated banking machine orpoint of sale machine.

FIG. 13 schematically illustrates an exemplary system implementing anidentity proofing and authentication method. The identity authenticationservices may be used to protect various activities requiring identityauthentication. The activities may or may not include the exchange ofmoney, goods, services, and/or information. The method or system may beused to grant access to sensitive and valuable assets such asinstitutional banking accounts, brokerage accounts, or financialservices. In the illustrated example, the accessing device 1309 may bean Automated Teller Machine (ATM), point of sale machine or kiosks. Auser 1303 may be authenticated in order to perform a transaction (e.g.,access bank account, cash withdrawal, deposit, printed accountstatement, swipe a card, etc) via the accessing device 1309.

The user 1303 may or may not register to the identity authenticationservice 1301 prior to the activity/transaction. In some cases, the usermay register to the identity authentication service 1301 by proofing anidentity of the user as described elsewhere herein. For example,different identity documents or materials may be used to uniquelyidentify a user. The identity-proofing assurance level may be affectedby different security levels of the identity documents and also affectedby how the identity proofing document is presented and examined.

During the registration, a user may be required to present an identityproofing document with various security features. The identity documentscan be authenticated in a variety of ways: signal, seal, special papersand inks, high quality engraving, holograms, cryptographic techniquesetc that make the identity documents recognizable and difficult to copyor forge. Various types of identity documents haven been well discussedelsewhere herein.

During the registration process, an identity document may be presentedor examined at different trust or confidence level. An identity documentmay be presented in different ways. The different ways may be in-personproofing, remote proofing or online proofing. In some cases, thedifferent ways may be categorized into multiple levels as describedelsewhere herein. For example, the first level of identity proofingassurance may not require an identity proofing document. A user may beasked to provide a federated account such as an email account toestablish an access to services provided by the identity authenticationservice system 1301. The federated account may be used as a singleauthenticated service account that can be re-used across multiple onlineservices. For example, the user account may be used to establish aconnection of the user to the transaction service provider such as thefinancial institution. Various other accounts can be employed such associal network account, email address and the like. The federatedaccount may be provided as a user identifier for uniquely identifying auser by the financial institution meanwhile providing a communication orverification channel between the user and the bank/identityauthentication service system. In some embodiments, the second level ofidentity proofing may require one or more identity proofing documents orthird party record, such as a driver license or a passport or ahealthcare record to be inspected remotely, such as a remote scan. Insome embodiments, the third level of identity proofing may require anin-person identity proofing to inspect one or more identity proofingdocuments with the high security level, such as a passport with NFCchip. In some cases, at all levels, a federated user account such as theemail account may be required.

In some embodiments, the users 1303 may provide their identity or anemail address to the identity authentication service 1301 when theyregister to the identity authentication service system. The identityauthentication service system may perform identity proofing of the userby requiring identity proofing document via certain presentation means.Once the identity of the user is proved, the identity authenticationservice 1301 may or may not issue one or more credentials to the users.The credentials can be used for later authentications. In some cases,once the identity of the user is proved, an access to the authenticationservices provided by the identity authentication service system may beestablished. For instance, the user may be allowed to use barcodescanning functions provided by a mobile application running on theidentity authentication server. The credentials may be generated lateras needed such as a QR code. As described previously, other differentcredentials may be used to authenticate a user. The credentials may ormay not contain an identity of the user. Optionally the credentials mayor may not contain attributes to the identity of the user. For example,the credential may contain verified name of the real user or pseudonyms.The credentials can be any form. The credentials may be physical objectsuch as a physical token that can be possessed and controlled by a user(e.g., paper credential, card, finger print reader, card reader, etc).The credentials may be electronic such as digital document that can bestored as data. The credentials can be secret information that the userknows such as user name and password. The same credentials may be usedrepeatedly for different authentication processes. Different credentialsmay be used for different authentication processes.

The identity authentication service 1301 may provide authenticationservices at different levels of assurance. In some embodiments, thefirst level may be a two-factor authentication. The first level ofauthentication may require something you know (e.g., PIN) and/orsomething you are (e.g. biometrics). For instance, a user may be askedto input a PIN or provide a fingerprint via a user device. In someinstances, the PIN is used for accessing the authentication applicationinstalled on the user device and provided by the user through the userdevice. In some instances, the PIN may be used for accessing the ATM andprovided by the user via the ATM. In some cases, anti-replay featuresmay be provided along with the credentials. In some embodiments, thesecond level may include an additional factor relative to the firstlevel. In some cases, the additional factor may be scanning of a visualbarcode or an identity proofing document (e.g., PDF 417 on a driverlicense) or scanning visual graphical barcode displayed on an externaldevice. For example, the first level of authentication may require auser to input a PIN or biometrics of the user at the user device toactivate an app provided by the authentication system and the secondlevel of authentication may require the user to scan a visual graphicalbarcode using the user device. This additional factor may be somethingyou have. In some embodiments, the third level may include use of aphysical token such as a magnetic card to provide additional securityrelative to the second level. In some embodiments, some or all of theauthentications are performed via a mobile application running on theuser device 1305. In some cases, the user device 1305 may bepre-registered with the identity authentication service system and havea unique device ID stored in a database that is accessible by theidentity authentication service system.

The one or more users 1303 may perform one or more transactions throughthe device (e.g., ATM) provided by the relying party (e.g., financialinstitution, bank) 1307. The relying party may be a financial servicesinstitution. The relying party may be a bank or other type of financialservices institution such as an insurance company, a credit union, abrokerage company, a mortgage company, an investment services company,or a combination thereof. The transactions may include, but not limitedto, access bank account, cash withdrawal, deposit, printed accountstatement, swipe a card and the like. Authentication may be required forperforming the transactions. Typically a user may be required to enterpersonal identification number (PIN) or account information to verifyidentity of a user. However such authentication method may increase theinconvenience that a user is required to memorize the PIN as well as therisk of phishing attack or eavesdropping. The provided method and systemmay allow for a user to access the RP-protected resource via the ATMwithout physically inputting a password. The authentication may beperformed by an identity authentication service 1301 via the userdevice. The identity authentication service 1301 will provide theverified user identity or approved user identifier to the financialinstitution. The identity authentication service can be the same as theidentity authentication service as described in FIG. 10.

The one or more users may perform transactions provided by the one ormore relying-parties via one or more accessing device 1309. Theaccessing device can be any devices provided by a financial institutionsuch as an ATM or point of sale machine. The accessing device may or maynot be portable. A user may access account information or financialservices provided by the transaction server 1307 via the ATM. Theaccessing device may be handheld. In some embodiments, the accessingdevice can be the same as display device as described in FIG. 1. In somecases, the ATM may comprise a display 1311, card reader 1313, userinterface 1315, cash module, a processor or a communication module.

The ATM or point of sale machine may comprise a display 1311 configuredto display one or more visual graphical barcode for authentication of auser. The display is used to display various information related to auser account, services, and the like. The display can be any type ofdisplay screen such as a liquid crystal display (LCD), cathode ray tube(CRT), light emitting diode (LED) display, touchscreen, electronic paper(e-paper) display, or a display on a separate computing device. The ATMor point of sale machine may also comprise a card reader 1313. The cardreader may comprise any type of device for reading information from abank or credit card. For example, the card reader may be configured toread magnetic strips, a chip and the like. The ATM or point of salemachine may comprise a user interface 1315. The user interface cancomprise any type of device for receiving a user input. The userinterface may include, for example, a keyboard, mouse, touchscreen,keypad, or button array. The user interface may include input device ofvarious other types configured for receiving a voice command, a fingerprint and the like. The ATM or point of sale machine may optionallycomprise a cash module which dispenses cash withdrawals, receives cashdeposits, or both. The ATM may comprise one or more processorsconfigured to run an ATM software in order to perform the one or moretransactions and services at the ATM.

The identity authentication service 1301 may include authorized agentwho is capable to authenticate identity proofing document in-person orremotely. The identity authentication service can be the same as theidentity authentication server as described in FIG. 10. The identityauthentication service 1301 may be configured to perform variousauthentications as required by various transactions as discussed above.The various authentications may include verifying user credentials withor without anti-replay features. The various functionalities of theidentity authentication service may be facilitated by use of one or moreprocessors. The identity authentication service may be facilitated byand/or have access to one or more databases. The identity authenticationservice may be implemented on one or more standalone data processingapparatuses. Alternatively, the identity authentication service may beimplemented on one or more processing apparatuses and/or databasesoffered by a distributed network of computers (e.g., peer-to-peer orcloud-computing based infrastructure). One or more functionalities ofthe identity authentication service may be part of a server or accessedby a server.

The identity authentication service may be in communication with one ormore user devices and/or one or more user credentials 1305. In someinstances, the authentication service may be in communication withvarious user devices and/or user credentials with aid of a communicationunit (e.g., an I/O interface). The identity authentication service maybe in communication with the transaction server 1307. In some instances,the identity authentication server may be in communication with theaccessing device 1309. The identity authentication service may be incommunication with the transaction server or the ATM with aid of one ormore I/O interfaces. For example, the I/O interface may facilitate theprocessing of a user input associated with a request for secureauthentication. Alternatively, the identity authentication server may bein communication with the transaction server only and not incommunication with the ATM.

The user devices, accessing devices (e.g., ATM), transaction server oridentity authentication servers may communication with each other viaone or more communication networks. The communication network(s) mayinclude local area networks (LAN) or wide area networks (WAN), such asthe Internet. The communication network(s) may comprisetelecommunication network(s) including transmitters, receivers, andvarious communication channels (e.g., routers) for routing messagesin-between. The communication network(s) may be implemented using anyknown network protocol, including various wired or wireless protocols,such as Ethernet, Universal Serial Bus (USB), FIREWIRE, Global Systemfor Mobile Communications (GSM), Enhanced Data GSM Environment (EDGE),code division multiple access (CDMA), time division multiple access(TDMA), Bluetooth, Wi-Fi, voice over Internet Protocol (VoIP), Wi-MAX,or any other suitable communication protocols. The communication betweenthe accessing device (e.g., ATM) and the transaction server may includebanking network. Banking network may include any number of membershiporganizations, banks, credit unions, or financial institutions. Thebanking network can use a variety of interaction methods, protocols, andsystems. For example, a banking network may use any of the automatedclearing house (ACH) networks. An ACH network may be operated by NACHA(previously referred to as the National Automated Clearing HouseAssociation). Another ACH network may be the Electronic Payments Network(EPN). These ACH networks may interact to settle ACH transactionsinvolving a party that has a relationship with only NACHA's ACH networkor only the EPN. Other banking networks, such as CIRRUS, NYCE, and PULSEmay also be used. In some cases, ATM networks such as an interbank ATMnetwork and/or intrabank ATM network may be included to enable thecommunication between the ATM and the transaction server.

The one or more user devices 1305 may be in communication with theidentity authentication service with respective credentials. In someinstances, a user device may be a user credential. The user device maybe used to scan a visual barcode displayed on the accessing device 1309for authenticating the user. The user device may be a computing devicethat is capable of executing software or applications provided by one ormore identity authentication service systems. In some embodiments, thesoftware and/or applications may allow the user to scan a visualgraphical barcode such as a QR code displayed on another device, andtransmit authentication data between the user device and identityauthentication service system during an authentication session. Thesoftware and/or application may have been registered with the identityauthentication service system by the user. Optionally, the softwareand/or application need not be registered with the identityauthentication service system, and only the user device may beregistered with the authentication system. Thus the device may have adevice ID stored in a memory accessible to the identity authenticationsystem. The user device can be the same as the user device as describein FIG. 10. In some embodiments, a visual graphical barcode basedauthentication method is provided for performing a financialtransaction.

FIG. 14 illustrates an exemplary method for authenticating a user with arelying party using a visual graphical barcode. A user may performauthentication during a transaction by scanning a visual graphical code.For instance, instead of inputting a PIN or password at the ATM, a usermay be authenticated by scanning a QR code displayed on the ATM. Therelying party may be a financial institution. The relying party mayemploy one or more transaction servers 1405 and a user may seek toperform transaction provided by the relying party via an accessingdevice 1401. The user may be authenticated by an identity authenticationserver 1407 via the user device 1403. The method may employ use of avisual graphical code. The visual graphical code 1409 displayed on adisplay of the accessing device can be any type of graphical code asdescribed previously herein. The visual graphical code may be referredto as visual graphical barcode or graphical authentication indicia. Insome instances, the visual graphical code may be a one-time visualgraphical code. The visual graphical code may expire or time out after acertain period of time or once they have been validated. The visualgraphical code may be a barcode as described elsewhere here. In somecases, the visual graphical code may be a QR code as described inFIG. 1. The visual graphical code may be displayed on a display screenof the accessing device. The accessing device may require authenticationor verification of the user to conduct a session or transaction. Thetransaction may involve service provided by the transaction server 1405.The accessing device can be the same as the accessing device asdescribed in FIG. 13. A user device 1403 may be used to scan the visualgraphical barcode for the authentication process. The user device can bethe same as the user device 104 as described in FIG. 1.

A user may desire to access an account or perform transaction providedby the transaction server 1405 via an accessing device 1401 (e.g., ATMor point of sale machine). For example, the user may try to access abank account or withdraw/deposit money through the cash module of theaccessing device. A transaction may be requested via various waysdepending on the protocols of the ATM or point of sale machine. Forinstance, a user may request a service or transaction associated with auser account by inserting a bank or credit card into a card reader ofthe ATM or select a service displayed on the screen. A processor of theATM may generate and transmit the request to the transaction server forauthentication. The user may not be required to input a user credential(PIN) or user identifier (username) in order for the ATM to send therequest. In some cases, a request for authentication may be generated inresponse to a user input indicating performance of a transaction orauthentication action. For instance, a user may press on a button orselect on the display screen indicating a selected service.Alternatively, the user may need to input a user credential or useridentifier such as inserting a bank or credit card into a card reader inorder to send the request. Next, the transaction server may generate arequest for a visual graphical barcode (e.g. QR code) 1413 and send therequest for barcode to the identity authentication server 1415. In someembodiments, the transaction server may generate the request for barcodeusing Application Programming Interface (API) or software developmentkit (SDK) provided by the identity authentication server 1407. Thesoftware running on the transaction server may generate and transmit arequest for the associated authentication or session to the identityauthentication server.

In response to the request, the identity authentication server maygenerate a visual graphical barcode along with an identifier uniquelyassociated with the barcode 1419. The visual graphical barcode may be aone-time barcode. In some embodiments, the identifier may be encoded inthe barcode to associate with the service session with the barcode. Theone-time barcode may be encoded with information such as the accessingdevice ID, service provider identity or session ID as describedelsewhere herein. Next, the one-time visual graphical barcode is sent tothe accessing device 1421. Alternatively, the one-time visual graphicalbarcode may be sent to the transaction server then the transactionserver may relay the one-time visual graphical barcode to the associatedATM. In some embodiments, the one-time barcode may be refreshed atcertain time interval. For instance, the one-time barcode may berefreshed every 10 s, 20 s, 30 s, 40 s, 60 s, 120 s, 5 minutes, 10minutes, and the like. In this case, the one-time barcode may beregenerated with refreshed information such as a new session ID ortimestamp while pertaining to the same transaction until it isvalidated. The one-time barcode may be refreshed when it is not scanned.This may be beneficial to avoid QR code hijacking and various otherattacks.

The visual graphical barcode is displayed on a display of the accessingdevice 1423. The display may be operably coupled to the accessingdevice. The display may be a component of the accessing device. The usermay scan the visual graphical code using the user device 1425. In somecases, nonce data may be collected during scanning. The captured visualgraphical code may be decoded and processed by the application orsoftware that is provided by the identity authentication server 1407 andrunning on the user device. In some instances, the image data of thevisual graphical code may be directly sent to the identityauthentication server along with the device ID. In other instances, theapplication or software may process the captured code (e.g. decode thecode or decrypt the decoded data) and send the decoded information suchas the identifier along with the device ID to the identityauthentication server 1427. In some embodiments, in addition to theidentifier and the device ID, nonce data may also be included to detectanti-replay attack. In some cases, the user may be required to log in tothe application or software using one or more user credential such asfinger print or password. The user credential may be required when theapplication is initiated or when a scanning is to be performed.

The identity authentication server may use the device ID to identify anassociated user 1429. In some cases, a user ID may be a user identifiersuch as a user name or user account that is used to register the userwith the identity authentication server. The user ID may or may notcontain private information about the user. In some cases, the user IDmay be a user identifier used only by the identity authenticationserver. In some instances, the user ID may be transmitted to theaccessing device 1431 to confirm continuing the process for theassociated user ID. For example, the user ID such as email account maybe displayed on the display screen of the ATM. A user may confirmrequest for authentication for the user ID via the accessing device(e.g., a tap on the screen, press a button on keyboard), then a requestfor accessing services provide by the transaction server using the userID is transmitted to the transaction server 1433. Alternatively, theuser ID may be sent to the transaction server directly instead of theATM. The transaction server may then send a request for verifying theuser ID to the identity authentication server 1435.

Next, the identity authentication server sends a request to theassociated user device for approval of verifying the user identity 1437.For instance, the user may be prompted on the user device indicatingverification or authentication is requested by the transaction server orgranting permission to proceed with the service provided by thetransaction server. The request may be sent via the federated accountsuch as the email address. The federated account may be used as a singleauthenticated service account that can be re-used across multipleservices as described elsewhere herein. In some cases, the request maybe sent via the application running on the user device. This approvalstep may add additional security to the authentication process. It maybe beneficial of being able to quickly detect and eliminate the risk ofQR code hijacking and various other attacks. In some cases, the user canchoose not to approve the request, for instance, when the user does notrecognize the bank or the service that requests authentication. It maybe indicative of a fraudulent event. In this case, the identityauthentication server may not provide any user related information tothe transaction server.

An approval for authenticating the user identity may be transmitted tothe identity authentication server when the user recognizes the bank orthe service 1439. Accordingly, the identity authentication server sendsa federated account such as email address used at least by thetransaction server for the server to identify the user 1441. Thetransaction server may determine authorization to the services orinformation as requested by the user associated with the federatedaccount 1443 and grant transaction on the accessing device 1445. In someinstances, if a bank or credit card is read by the ATM, the transactionserver may also compare the federated account with pre-stored userrelated information associated with the bank or credit card to determineauthorization to the services. In some cases, instead of or in additionto the federated account, information related to the user identity maybe provided by the identity authentication server to the transactionserver. The identity authentication server may determine the type ofinformation related to an authenticated user to be provided to thetransaction server. In some cases, once a user is authenticated, only afederated account or user identifier that is recognizable by theassociated transaction server may be provided which may minimize therisk of exposing user information to a malicious party. The identityauthentication server may not need to have access to the user'sfinancial account or service provided by the transaction server. In somecases, the federated account may be the only information shared betweenthe transaction server and the identity authentication server. In somecases, additional user related information such as user name, device ID,address and the like may be shared between the transaction server andthe identity authentication server.

It should be noted that the method should not be limited to the processas described above. One or more steps may be skipped or the order of thesteps may vary according to different applications. For example, thesteps 1437, 1439 for user approval of the authentication may be optionalsuch that a user may be automatically approved or authenticated byscanning a visual graphical barcode without providing additional userinput.

As described above, the authentication system and method can be used inconjunction with various types of transactions. In some cases, as longas the transaction involves a display device, a visual graphical codebased authentication can be performed. The various transactions shouldnot be limited by the examples illustrated herein. FIG. 15 shows anexample of performing authentication for a transaction via a TV 1509.The TV 1509 may be a smart TV, connected TV or hybrid TV. The TV may beequipped with integrated Internet features such that to provide InternetTV, online interactive media, over-the-top content, on-demand streamingmedia, or home networking access in addition to traditional broadcastingmedia. The TV may comprise one or more processors to perform one or moretransactions with a user 1503. The one or more processors may beprovided on a set-opt box (STB) 1515 of the TV. In an example, thetransaction may include accessing an online streaming, purchase apps,games or movies via the set-top box (STB) 1515. The STB may beconfigured to stream audio and video from an online resource provider,and may be connected to an external display, such as monitor or thetelevision. The TV set may include a remote control 1513. The remotecontrol may allow a user to control some basic functions of the TV, turnthe TV on and off, adjust volume, or switch between digital and analogTV channels or between terrestrial and internet channel. The remotecontrol may also allow a user to input transaction related informationsuch as information required to login to a user account registered witha media server or any similar media service 1507, select a media fortransaction, financial information for the transaction and the like.

The media server 1507 may provide any media or multi-media service to auser via the TV set. For instance, the media server may provide accessto pre-recorded and/or live video streams. Various multi-media servicesmay include but not limited to, streaming video content, music, photos,shows, apps, interactive advertising, social networking, voting,video-on-demand, and other content provided by the media server 1507.For a user to perform a transaction with the media server, an identityauthentication service 1501 that is acceptable to the media server willauthenticate the user identity using one or more credentials, and theidentity authentication service 1501 will provide the verified useridentity or approved user identifier to the media server. The one ormore credentials may include using a visual graphical barcode 1511displayed on the TV to authenticate the transaction or the identity ofthe user.

The user 1503 may desire to access a service such as streamingentertainment service (e.g., game, movie, or app) or purchase a productvia the STB. During the process, the user may be authenticated in orderto access the service or perform a transaction. In this case, the usermay be authenticated by scanning a visual graphical barcode 1511displayed on the television or monitor using a user device 1505. Theauthentication process can be the same as described elsewhere herein.The user 1503 and the user device 1505 may be the same as the user anduser device as described in FIG. 10 or FIG. 13. The identityauthentication service 1501 can be the same as the identityauthentication service as described in FIG. 10. For example, when a userdesires to purchase a media or service (e.g., game, app, or movie), arequest may be submitted by the user via the TV or the remote control.The user may login to a user account registered with the media serviceprovider by inputting a user account ID through the remote controland/or input instructions indicating the purchase. The identityauthentication service 1501 may generated a QR code associated with thetransaction and displayed on the monitor or TV screen 1509. The QR codemay be displayed on a static image frame or displayed on top of dynamicimage frames. For instance, the QR code may be displayed on a statictransaction screen or displayed on top of a media that is beingdisplayed. Alternatively or additionally, the authentication may beperformed for the user to access the user account where pre-storedfinancial information with the user account may be used for thetransaction once the identity of the user has been approved by theidentity authentication service. The user may scan the QR code using theuser device then the verified user identity may be transmitted by theidentity authentication service to the media server in order to completethe transaction.

While preferred embodiments of the present invention have been shown anddescribed herein, it will be obvious to those skilled in the art thatsuch embodiments are provided by way of example only. It is not intendedthat the invention be limited by the specific examples provided withinthe specification. While the invention has been described with referenceto the aforementioned specification, the descriptions and illustrationsof the embodiments herein are not meant to be construed in a limitingsense. Numerous variations, changes, and substitutions will now occur tothose skilled in the art without departing from the invention.Furthermore, it shall be understood that all aspects of the inventionare not limited to the specific depictions, configurations or relativeproportions set forth herein which depend upon a variety of conditionsand variables. It should be understood that various alternatives to theembodiments of the invention described herein may be employed inpracticing the invention. It is therefore contemplated that theinvention shall also cover any such alternatives, modifications,variations or equivalents. It is intended that the following claimsdefine the scope of the invention and that methods and structures withinthe scope of these claims and their equivalents be covered thereby.

1. (canceled)
 2. A network-enabled method for creating an online accountusing a network of devices, said method comprising: (a) receiving, by anauthentication system, a request from an online server to create anonline account with the online server for a user; (b) in response tosaid request, generating a visual graphical code by the authenticationsystem, wherein the visual graphical code is encoded with a validationidentity that is associated with the online server or an online serviceprovider that is operating the online server; (c) acquiring an imagedata of the visual graphical code from a user device of the user,wherein the image data is received along with an identificationinformation related to the user; (d) extracting the validation identityby processing said image data to authenticate the online serviceprovider; (e) based on the validation identity, identifying the onlineservice provider associated with the online server; (f) accessing amemory storage space to retrieve one or more pre-stored user informationcategories associated with the online service provider based on theidentified online service provider, wherein the one or more pre-storeduser information categories are requested by the online service providerto create an online account with the online service provider; and (g)providing, based on the identification information related to the user,user information data according to the user information categories tothe online server for the online account to be created with the onlineserver.
 3. The method of claim 2, wherein the request received from theonline server encodes an identity of the online server.
 4. The method ofclaim 2, further comprising consolidating different labels fromdifferent online serve providers into a label indicating a same userinformation category.
 5. The method of claim 2, further comprisingidentifying the one or more user information categories that is notpre-stored in the memory storage space, and prompting the user toprovide user information according to the identified one or more userinformation categories via the user device.
 6. The method of claim 2,wherein the visual graphical code is a one-time barcode that is uniquelyassociated with opening the online account.
 7. The method of claim 2,wherein the identification information related to the user comprises adevice identifier of the user device.
 8. The method of claim 2, furthercomprising receiving nonce data along with the image data for detectinga replay attack.
 9. The method of claim 8, wherein the nonce datacomprises at least two of the following: (i) one or more operationalparameters of the imaging, (ii) positional information about the imagingdevice or the user device, and (iii) characteristics of the image dataderived from image processing of the image data.
 10. The method of claim9, wherein the nonce data comprises data about a location of the usertouching on a touch screen of the user device.
 11. The method of claim2, further comprising generating an authentication code by theauthentication system for authenticating the visual graphical code. 12.An authentication system for creating an online account using a networkof devices, the system comprising: an authentication server incommunication with a user device configured to permit a user to createan online account with an online server, wherein the authenticationserver comprises: (i) a memory for storing a set of softwareinstructions, user information data for each of a plurality of users anda plurality of information categories uniquely associated with each of aplurality of users, and (ii) one or more processors configured toexecute the set of software instructions to: (a) receive a request froman online server to create an online account with the online server fora user; (b) in response to said request, generate a visual graphicalcode, wherein the visual graphical code is encoded with a validationidentity that is associated with the online server or an online serviceprovider that is operating the online server; (c) acquire an image dataof the visual graphical code from a user device of the user, wherein theimage data is received along with an identification information relatedto the user; (d) extract the validation identity by processing saidimage data to authenticate the online service provider; (e) based on thevalidation identity, identify an online service provider associated withthe online server; (f) access a memory storage space to retrieve one ormore pre-stored user information categories associated with the onlineservice provider based on the identified online service provider,wherein the one or more pre-stored user information categories arerequested by the online service provider to create an online accountwith the online service provider; and (g) provide, based on theidentification information related to the user, user information dataaccording to the user information categories to the online server forthe online account to be created with the online server.
 13. The systemof claim 12, wherein the request received from the online server encodesan identity of the online server.
 14. The system of claim 12, whereinthe one or more processors are configured to further consolidatedifferent labels from different online serve providers into a labelindicating a same user information category.
 15. The system of claim 12,wherein the one or more processors are configured to further identifythe one or more user information categories that is not pre-stored inthe memory storage space, and prompt the user to provide userinformation according to the identified one or more user informationcategories via the user device.
 16. The system of claim 12, wherein thevisual graphical code is a one-time barcode that is uniquely associatedwith opening the online account.
 17. The system of claim 12, wherein theidentification information related to the user comprises a deviceidentifier of the user device.
 18. The system of claim 12, wherein theone or more processors are configured to further receive nonce dataalong with the image data for detecting a replay attack.
 19. The systemof claim 18, wherein the nonce data comprises at least two of thefollowing: (i) one or more operational parameters of the imaging, (ii)positional information about the imaging device or the user device, and(iii) characteristics of the image data derived from image processing ofthe image data.
 20. The system of claim 18, wherein the nonce datacomprises data about a location of the user touching on a touch screenof the user device.
 21. The system of claim 12, wherein the one or moreprocessors are configured to further generate an authentication code bythe authentication system for authenticating the visual graphical code.